Your app fires three notifications inside a minute and the player’s phone shows them one banner. That is not a bug in your push provider. It is the Android notification cooldown, shipped on by default in Android 16, and it quietly rewrites the rules for every high-volume sender. If you run push for a betting or gaming app, your most valuable moments are exactly the ones it targets: a goal, an odds move, and a cash-out prompt land within the same sixty seconds. This post covers what the cooldown does, the FCM rate limits that were already there underneath it, and the send-design patterns that keep your app heard.
What the Android notification cooldown does to a burst
Android 16 reached stable on June 10, 2025, and notification cooldown shipped with it, enabled by default. The behavior was first documented in the Android 16 developer previews in late 2024, when it was still an opt-in toggle. In the stable release, Google flipped it on for everyone.
The mechanics are simple. When an app sends a burst of notifications, the first one alerts normally, at full volume, with a full banner. Each subsequent notification in the burst is progressively lowered in volume and visually minimized, for up to one minute, and the burst is grouped under a single banner. Nothing is deleted. The notifications still arrive, still sit in the tray, still count in your delivery reports. They just stop demanding attention.
That last point matters for how you read your dashboards. Delivery rate will not move. What moves is everything downstream of attention: views, clicks, and the conversions your second and third sends were supposed to drive.
Android 16 notifications: what still alerts, what gets quieted
The cooldown does not treat all Android 16 notifications the same. Calls, alarms, and priority conversations are exempt; they alert normally no matter how fast they stack. Everything else is subject to the quieting curve, and that covers all betting app notifications, marketing and transactional alike.
One applicability note, and it is an inference rather than a documented platform statement: the cooldown operates at the notification layer, so by mechanism it should apply both to FCM-delivered app pushes and to web push notifications that Chrome renders on Android. If your brand runs both an app and a mobile site, treat Android 16 notifications from both channels as sharing one attention budget on the same device.
FCM rate limits were already capping you
The cooldown is the visible layer. Underneath it, Firebase Cloud Messaging has enforced per-device throttling for years. The FCM documentation sets the caps at 240 messages per minute and 5,000 per hour to a single device, and warns that senders running near those limits risk having the app flagged as abusive.
No sane campaign hits 240 messages a minute to one user. But these FCM rate limits are per device, not per campaign, which means every system you run sends against the same shared budget: your CRM, your trading engine’s odds alerts, your promo scheduler, your transactional layer. An architecture where four systems each behave reasonably can still produce a device-level pattern that reads as abuse to FCM and as a burst to the cooldown.
The two mechanisms compound. FCM rate limits cap what can physically arrive; the Android notification cooldown decides how much of what arrives gets noticed. High-volume senders now design against both at once.
Why betting app notifications burst in the first place
Betting apps do not burst because CRM teams are careless. They burst because the product’s best moments are inherently simultaneous. A goal in a followed match is, in the same instant, a score alert, an odds movement, and a cash-out opportunity. Three different systems each own one of those messages, and none of them checks what the other two just sent.
Here is the burst as the player’s phone experiences it under cooldown:
| Time | System | Meddelande | What the player experiences |
|---|---|---|---|
| 0:00 | CRM / event feed | “GOAL. 1–0 in the match you follow” | Full alert: sound, vibration, banner |
| 0:15 | Trading engine | “Odds shifted on the next goal market” | Quieted: reduced volume, minimized, grouped |
| 0:40 | Promo engine | “Cash out now available on your open bet” | Quieted further: near-silent, collapsed into the group |
The painful part is the ordering. The cash-out prompt, the one notification in that burst with direct revenue attached, is the one the cooldown buried, because it arrived third. Whoever sends first owns the minute. Right now, in most betting app notifications stacks, the winner is whichever system has the lowest latency, not the message that matters most.
The match-day push sequence has always needed deliberate sequencing. The cooldown turns that from craft into requirement.
Design patterns that survive push notification bursts
You cannot toggle the cooldown off for your users, and you should not want to; it punishes exactly the pattern your players already resented. The fix is architectural. Four patterns keep push notification bursts from eating your reach.
Space sends by minutes, not seconds
The cooldown window runs up to a minute. Any two notifications you control that land inside that window compete for one alert. So enforce a per-subscriber gap measured in minutes between distinct messages, and enforce it everywhere, including the transactional path most teams forget to count. A goal alert at 0:00 and a cash-out prompt at 2:30 both alert normally. The same pair thirty seconds apart is one alert and one ghost.
Assign the burst a single owner
For every predictable moment, decide in advance which one notification owns it. When a goal happens, does the score alert, the odds move, or the cash-out prompt fire? Pick one, usually the one closest to revenue or the one the player explicitly subscribed to, and suppress or delay the rest. Priority tiers beat racing systems.
Collapse updates into one notification
Odds tracking is the classic offender: five odds movements should not be five notifications. Use message replacement, where the new payload updates the existing notification in the tray instead of stacking a new one. FCM has supported collapse behavior for years. One live, continuously updated odds notification never triggers the cooldown, and it reads as a feature rather than as noise.
Stagger the fan-out by segment
A 500,000-subscriber blast that leaves in one wave produces bursts at the population level too, colliding with whatever else your systems send in that window. Break the fan-out into segment waves: live-bettors on the followed match first, recent depositors next, cooler segments minutes later or not at all. Your player segmentation model already defines the waves; the fan-out just needs to respect them.
Notification frequency capping and quiet hours finish the job
The four patterns above fix the minute. Notification frequency capping fixes the day and the week. The cooldown is Google enforcing, at the OS level, a discipline that the best senders already imposed on themselves, and it will not be the last enforcement mechanism. Set house ceilings per subscriber per day and per week, and scale them by segment heat:
| Segmentering | Max/day | Max/week |
|---|---|---|
| Active last 7 days, follows live events | 3–4 on match days | 10–12 |
| Active last 7 days, casino rhythm | 2 | 8–10 |
| Lapsing, 8–20 days quiet | 1 | 3–4 |
| Dormant, 21+ days | — | 1, then re-engage or suppress |
Quiet hours are the hard floor under the caps: define a do-not-disturb window and let nothing marketing-shaped cross it. In this vertical, notification frequency capping is also player protection, not just deliverability hygiene. Caps, quiet hours, and a strict no-urgency rule on deposit prompts are the same practice viewed from two angles, and operators who hold that line give players a reason to leave notifications on. The retention playbook for betting sites covers the full hygiene stack.
Building the spacing discipline in PushEngage
Every pattern above is buildable in PushEngage Workflows today, without custom send infrastructure. Betting and gaming sites on PushEngage have sent over 3.5 billion notifications, and the send-shaping controls exist because senders at that volume need them.
Wait nodes, available on Business plans and above, are the spacing primitive: insert a wait of minutes, hours, or days between any two sends in a workflow, so no sequence you design can burst a subscriber. Decision nodes and exit criteria, on the same plans, are how a workflow checks state before firing, which is what “assign the burst one owner” looks like in practice: if the higher-priority message already went out, exit instead of piling on.
Quiet hours are configured per workflow with a fallback you choose: skip the send outright, or reschedule it for one minute after the window ends, resolved in each subscriber’s own timezone. Use reschedule for offers with a shelf life and skip for moment-bound alerts; a kickoff notification delivered at 09:01 is noise. Timezone-aware scheduling also gives you segment-staggered fan-out without scripts, since waves can leave on local time rather than as one global blast.
Two capabilities sit higher in the plan ladder: A/B split paths inside a workflow start on Premium, and custom-event triggers and webhooks, the pieces that let your trading engine or wallet events start a workflow directly, start on Growth. If you are mapping the full app-side setup, start with push notifications for betting apps, the pillar guide for this series.
Chrome is running the same play on the web
If you also run web push, the same engagement logic now polices that channel. Since January 2026, Chrome scores every sending origin daily on pushes relative to time users actually spend on the site, and throttles senders it classifies as disruptive. Different mechanism, identical message: platforms now meter attention, and senders who target engaged users keep their reach while blasters lose it. The web-side version of this story, and the segment architecture that answers it, is covered in why segmentation is now a deliverability requirement.
What to change before your next match day
Three moves, in order. First, audit last month’s sends for same-device push notification bursts: pull any subscriber who received two or more notifications inside a minute, identify which systems collided, and note how often the buried notification was the one with revenue attached. Second, assign each predictable moment a single owning notification and demote the rest to collapsed updates or delayed follow-ups. Third, move every recurring sequence into workflows with wait nodes, frequency caps, and quiet hours, so spacing is enforced by the platform rather than by team memory.
The Android notification cooldown did not take your reach away. It took away the illusion that three notifications in a minute were three chances to be seen. The senders who space, prioritize, and collapse will alert at full volume while their competitors’ bursts collapse into a silent group. If you want the send-shaping controls without building them, app push notifications on PushEngage ship with wait nodes, quiet hours, and timezone scheduling on every paid plan tier, backed by a 14-day money-back guarantee.
