The cap's reset period must be visible

What it is

"Five a day" does not say which day, and when it zeros. Local midnight, a rolling 24 hours, UTC midnight, Monday morning—four clocks turn the same sentence into four experiences: someone thinks the budget is spent, then another item arrives; someone waits for midnight expecting a stop, then a rolling window opens a slot. The reset period must live where people can see it, and it must match the real counter.

This is only whether the quota's clock is intelligible. It does not say whether caps should be independent per type, and not who may pierce quiet hours.

Why it happens

People use a cap to form an expectation: "two more then it stops," "it will ring again tomorrow." Expectation needs a shared origin. When the origin is hidden on the server, expectation cannot form, and arrivals are read as the system not meaning what it said. Rolling windows are especially unintuitive: the last item just arrived, the right edge slides, a slot opens, and it feels like "I thought it was full." A civil day matches the everyday word "daily," but travel can split one day into two.

Opacity is also read as cheating. A marketing cap that resets at UTC midnight is early evening in North America—another round that looks like a dodge of "daily," even when the counter is literally correct.

Studying it

Give the same cap different reset clocks, ask "can another one come, and how long until then," and compare with the actual next arrival.

Independent variables: local day-cut vs rolling window vs UTC; whether settings show the next reset time. Dependent variables: gap between expectation and actual, share who judge a further arrival as "broke its word," type-off or permission-off to make it stop.

Lab "what does daily mean to you" only yields linguistic intuition; pair it with a real arrival after the cap is spent. Complaint volume is a weak sole metric—many people will not complain, they will kill the channel.

Where it stops holding

Internal quotas that never promise a number to the user need not show a clock; once copy or settings say "per day / per week," the clock must be public. Session-priced IM usually has no "N a day" product promise; adding reset copy invents a cap that does not exist. Counters for legally required delivery and marketing quotas must not share one "remaining today" sentence.

Applying it

• Whenever a cap is promised, write the reset rule: local civil day, rolling duration, or a named weekday, and show the next zero in local time.
• Counter and copy must share a clock; do not say "daily" and count UTC.
• When a type is spent, the next attempt should say "at cap, resumes at HH:MM" rather than dropping silently and leaving people to guess.
• Verify by having someone spend a type to the cap and ask when the next item will come. If the answer disagrees with the counter, change copy or clock until they match. Repeat after a timezone-crossing day to see whether the local day-cut still holds.

Related

• Within the group: H5.10.1 Caps should be per type, not one shared budget · H5.10.2 Quiet hours must still let high-urgency items through · H5.10.3 Queue pending items into one send window instead of dripping them
• Adjacent: H5.07 Push frequency · H5.09 Category subscriptions · H5.05 Badges and unread counts
• Search terms: cap reset · daily limit · rolling window