Quiet hours are a product decision, not a settings afterthought
Someone's phone lights up at 1:40 a.m. because a batch job finished and the app had something to say. If you ship push notifications, decide when silence is the feature—and encode it before the store review comments write the policy for you.
Before the next notification type ships, write quiet hours per audience, which events may break them, how local time is known, and how a user turns the noise down without deleting the app. Test the overnight path on real devices. Treat marketing pushes and operational alerts as different products with different override rules.
Start with who gets woken
List every push your app can send today—or will send in the next release. For each row: audience (customer, field worker, admin), purpose (security, delivery, marketing, social), and whether a human is expected to act immediately.
If every event can wake someone, none of them feel urgent. Quiet hours exist so the few true emergencies still cut through.
This is a checklist you can run in one working session with product, mobile engineering, and whoever owns support.
If you cannot produce the inventory list in an hour, your notification surface is already out of control. Pause new types until the list exists. Product managers often discover "temporary" debug pushes that have been waking beta users for months.
How the work moves
Quiet-hours decisions in order
- Inventory
List every push type and who it wakes.
- Policy
Set default windows and the override allow-list.
- Controls
Ship settings users can find without deleting the app.
- Prove
Force overnight time in staging on real devices.
- Watch
Review overnight sends and mute reasons in week one.
Checklist: policy before pixels
Print it. Put initials next to each line. Ship blockers stay blockers.
For multi-brand or white-label apps, quiet hours may need to be brand-specific. A hospitality brand and a logistics brand sharing a codebase rarely share the same night. Encode brand in the policy table, not in a hard-coded hour.
If every event can wake someone, none of them feel urgent.
Checklist: engineering proof
If any line fails, the feature is not done. Related reading: sort notifications before users do for in-app inbox hygiene; this checklist is specifically about waking the hardware.
Watch for vendor SDKs that send their own pushes (marketing suites, chat vendors, cart abandon tools). Your quiet-hours policy is incomplete if a third-party SDK can still sound the device. Inventory those SDK keys the same week.
Decision guide
Marketing push vs operational alert
| Consideration | Marketing / social | Security / operational |
|---|---|---|
| Quiet hours | Always respect; never override. | May override only if listed. |
| User mute | Easy category mute is required. | Mute limited; security path stays. |
| Digest | Prefer digest over night pings. | Live send when policy allows. |
| Copy tone | Optional, skippable. | Actionable, specific. |
| Failure mode | Annoyance and uninstall. | Missed fraud or missed dispatch. |
Checklist: release and review
Field and ops apps often need different quiet rules than consumer apps—workers on night shifts live in inverted windows. Ride along before you copy a consumer default into a mobile application used on the floor.
When reviewers or customers complain about overnight noise, resist the urge to answer only with "turn on Do Not Disturb." Own the product default. OS protections are a backstop, not your design.
What "done" sounds like
Users still get the fraud code at 1:40 a.m. They do not get a "people also liked" carousel. Admins can explain a rare override. Engineering can disable a noisy type in minutes. Product can point to a dated policy, not a Slack shrug.
Executives sometimes ask for "more engagement." Translate quiet hours into the metric they actually want: fewer uninstalls, higher opt-in retention, better response to the rare urgent push. Noisy apps train people to swipe away everything—including the fraud code.
Edge cases worth writing down.
Travel: a user flies overnight and local time jumps. Decide whether quiet hours follow the device clock (usually yes) and document it. Shared family devices: prefer account-level quiet hours over device-only assumptions. B2B admin apps: an overnight batch failure may need to page an on-call role while never notifying the end customer. Those are different notification products sharing one codebase—configure them apart.
International: quiet hours in one country may be business morning in another for the same event (global admin alerts). Segment by role and region in the policy table. If that sounds heavy, start with consumer-end-user quiet hours only and keep admin alerts on a separate channel such as email or PagerDuty.
Finally, align analytics. If your engagement dashboard celebrates overnight open rates, quiet hours will look like a regression. Change the dashboard before you ship the policy, or someone will "fix engagement" by turning the noise back on. Measure seventh-day retention and opt-in rate instead of 2 a.m. opens.
When you inherit an app, assume quiet hours were never designed. Run the checklists before you add growth pushes on top of an already noisy binary. Inherited apps often contain hard-coded "send immediately" flags from early debugging. Hunt those flags the same week you hunt API keys in the binary—different risk, same "what did we actually ship" discipline.
Contractors who send manual pushes from a vendor console can bypass your carefully built quiet hours. Put contractual language and console permissions next to the engineering checklist. Product policy that only binds your own API is half a policy.
Put this into practice
Run both checklists against your current push catalog this week. Fix the overnight path before you add a new notification type for the holiday campaign. If the catalog is a mess and you need a rebuild plan—talk to us.
Related work: Workstep.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.