Frequency · 9 July 2026
Quiet hours are a measurement problem
A suppression window that only knows clock time will keep tapping muted devices. Quiet Hours Lab starts from the join, not from the policy slide.
Most “quiet hours” documents are written by CRM and approved by legal. They specify a clock window, maybe a time zone, sometimes an exception for safety. They rarely specify how you will know whether the device was able to pay attention.
Unsent is not the same as unheard
If your only metric is “messages not sent between 22:30 and 06:00,” you can pass an audit and still annoy people. Tokens remain valid. Mute state is on. The first morning send lands in a pile. Unsubscribes cluster after breakfast, and the recap still says quiet hours are working because night volume dropped.
Nicha’s ride-hailing team, whose note is on our alumni page, had exactly this shape. Safety pings were exempt. Everything else was “quiet.” Mute state was not in the grain. Once they joined it, late-night unsubscribes made sense: exempt pings were still landing on silenced phones, and non-exempt traffic had simply moved to 06:05.
Render windows belong in the policy
Quiet Hours Lab treats render time as part of the rule, not as a downstream vanity. If an in-app card is allowed to sit for twelve hours, a “no send after 21:00” rule is incomplete. The card is still a message. Lifecycle messaging analytics has to count it on the same map as push.
What to instrument first
Before you rewrite the policy, ask: can we see OS mute or notification permission at send time? Can we see whether a push rendered? Can we separate safety traffic? If the answer to the first two is no, the policy is theatre. Fix the warehouse access, then write the rule. That order is unpopular. It is also why the lab exists.