Somewhere in the last eighteen months, the platforms stopped asking senders to behave and started enforcing it. Chrome now rate-limits sites it classifies as disruptive and silently revokes notification permission from sites users ignore. Android 16 quiets notification bursts by default, force-groups everything, and on newer Pixels files promotional pushes into a collapsed, silent bundle. Google Messages caps how many new users a low-reputation RCS sender can even reach. If you searched “chrome notification crackdown” or “why are my push notifications not delivered,” this page is the reference: every change, the primary source behind it, who it hits, and the specific fixes that keep a sender delivered.
This is a living document. We update it when a platform ships or announces a change, and every revision is logged in the changelog at the bottom. Last updated: August 17, 2026.
One framing note before the details, because it explains every entry in the table below. None of these platforms is killing notifications. All of them are splitting notifications into two classes: high-volume, low-engagement sends get throttled, silenced, bundled, or unsubscribed — while relevant, event-driven notifications keep full delivery, and in some cases get better placement than before. The crackdown is not on push. It is on blast.
What changed: the 2026 notification crackdown timeline
| Platform | Change | Who’s affected | Effective | Source |
|---|---|---|---|---|
| Chrome (desktop + Android) | Quieter permission UI: muted prompt for users who usually block and for sites with low prompt-acceptance rates; later extended to sites with abusive prompts or content | Sites that prompt on first pageview or push deceptive content | Chrome 80, Feb 2020 (enforcement extended through 2020) | Chromium blog |
| Safari / iOS | Declarative Web Push: web push without a service worker, no silent-push penalty for declarative payloads | Web push senders targeting Apple users | iOS/iPadOS 18.4 (Mar 2025); Mac in Safari 18.5 (May 2025) | WebKit blog |
| Chrome on Android | On-device ML flags suspicious web push notifications as “possibly deceptive or spammy” with one-tap unsubscribe | Senders whose notification copy pattern-matches spam | May 2025 | Chromium blog |
| Android 16 | Notification cooldown (bursts progressively quieted, on by default) and forced grouping of every app’s notifications | High-frequency app-push senders; bursts of any kind | Stable June 10, 2025 | Android Authority; our deep dive |
| Chrome (desktop + Android) | Automatic notification permission revocation via Safety Check for low-engagement, high-volume sites | Sites sending lots of notifications that users never click | Announced Oct 10, 2025; rolling out | Chromium blog |
| Google Messages | “Unknown senders” grouping; verified-business checkmarks and standardized branding for RCS | Businesses messaging users who haven’t saved them | From mid-Oct 2025 (rolling out) | Android Authority |
| Android 16 QPR2 (Pixel) | Notification Organizer: on-device AI files Promotions and News notifications into a silent, collapsed bundle by default; AI summaries for conversations | Promotional app-push senders on current Pixels (6 countries, English) | Dec 2025 | 9to5Google |
| Chrome (desktop + Android) | Push API rate limits: sites classified as disruptive capped at 1,000 push messages/minute with HTTP 429 above it; 1 → 7 → 14-day penalty ladder | High-volume senders with low per-user engagement | Rolling out from Jan 2026 | Chrome for Developers |
| RCS for Business | Reputation-based traffic limits: unique-user caps per rolling 28 days for low-reputation promotional agents (live in India; new agents start at low reputation); spam-trend and unsubscribe-reason analytics | Promotional RCS senders, especially new agents | Jan 7 / Feb 16 / Apr 1, 2026 | RCS for Business release notes |
Now the per-platform detail, in the order it will hit your dashboard.
Chrome: rate limits, auto-revoked permissions, and ML spam screening
Chrome is where most retention teams feel the crackdown first, because web push is the highest-volume owned channel most eCommerce brands run. Three separate mechanisms are now live, and they compound.
Push API rate limits for “disruptive” sites
Since January 2026, Chrome evaluates every site daily against three factors: push messages sent per time users spend on the site, permission prompts shown per time on site, and the user’s engagement level with the site (site engagement score plus foreground minutes). A site that fails the test is classified as disruptive and capped at 1,000 push messages per minute. Everything above the cap gets an HTTP 429 response from the push service.
The penalty escalates. The first disruptive day earns a 1-day limit. A second consecutive day extends it to 7 days. From the third day on, the limit runs 14 days at a time — and the counter only resets after 42 consecutive days of clean behavior. Google has not published a Chrome version number for the rollout; the mechanism is server-evaluated and arrived quietly.
Do the arithmetic against your own list. At 1,000 messages per minute, a 500,000-subscriber send takes more than eight hours to finish. A flash-sale push that needed to land in fifteen minutes now lands across a full workday, and the revenue window it was supposed to hit is gone. That is the actual cost: not a ban, a decay — your recovered-cart revenue and click-to-revenue numbers erode while your delivery dashboard still says “sent.”
Note the scope. The limit applies to the background Push API only; notifications fired from an open tab via the Notifications API are unaffected. Google’s own framing is that “nearly all websites will be unaffected” — the target is the small set of senders pushing high volume into an audience that has stopped responding. Whether you are in that set is a measurable question, and the self-audit below walks through it.
Automatic permission revocation
The second mechanism removes subscribers you thought you owned. Announced October 10, 2025, Chrome’s Safety Check now automatically revokes notification permission from sites that combine very low user engagement with a high volume of notifications sent — the same treatment it already applied to unused camera and location permissions. Chrome’s product team justified it with one number: less than 1% of all notifications receive any interaction from users.
The details that matter for a sender:
- Installed web apps are exempt. A subscriber who added your site to their home screen or desktop keeps the permission.
- The user is notified when Chrome removes a permission, and can restore it through Safety Check or by revisiting your site and opting back in.
- Google reported that in testing, notification overload dropped significantly with “only a minimal change in total notification clicks” — and that sites sending lower volumes saw click rates rise.
Read that last point again, because it is the whole crackdown in one sentence. The clicks were never in the tail of the list. Sites that sent less earned more per send. Chrome is now enforcing the list hygiene that high-performing senders were already practicing: your inactive segment is no longer a vanity number on the subscriber counter, it is a liability that triggers enforcement.
Google has not published the numeric thresholds for “low engagement” or “high volume,” so no vendor can promise you a safe ceiling. What you can control is the ratio the system is plainly measuring: interactions per notification delivered.
On-device ML screening on Android
The third mechanism, live since May 2025, puts a machine-learning model between your notification and the user’s eyes. Chrome on Android analyzes incoming web push content on the device (web push is end-to-end encrypted, so the analysis must be local — the model reads the title, body, and action-button labels). Notifications that pattern-match deception or spam are shown with a warning and a one-tap unsubscribe option.
The copy habits that trip spam classifiers are the ones low-quality senders lean on: fake urgency, clickbait gaps, misleading system-message styling. If your notification copy could be mistaken for a prize-scam template, on some phones it now ships with a warning label and an exit door attached.
What Chrome’s history tells you about what comes next
None of this is a swerve. Chrome muted the permission prompt for low-acceptance sites in February 2020, then extended enforcement to abusive prompts and abusive content later that same year. The 2025–2026 wave moves enforcement from the opt-in moment to the sending relationship itself. The direction has been one-way for six years: every release makes engagement more load-bearing. Plan on the thresholds tightening, not loosening.
Android 16: cooldown, forced grouping, and the silent Promotions bundle
Android’s changes hit app push rather than the browser, and they change what “delivered” means rather than whether delivery happens.
Notification cooldown, shipped on by default when Android 16 went stable on June 10, 2025, targets bursts. The first notification in a burst alerts at full volume with a full banner; each subsequent one within roughly a minute is progressively quieter and visually minimized, and the burst collapses under a single banner. Calls, alarms, and priority conversations are exempt; marketing and transactional pushes are not. Nothing is deleted and delivery reports do not move — which is exactly why the change is dangerous. Your dashboard says three delivered; the user’s phone presented one. We published a full teardown of the mechanics and the send-design fixes in our Android 16 notification cooldown guide.
Forced grouping removes a choice developers used to have: Android 16 bundles all notifications from the same app whether or not the app opted in. Combined with cooldown, the second and third pushes of any rapid sequence are now quiet, collapsed line items rather than banners.
The Notification Organizer is the sharpest of the three. Rolling out since December 2025 with Android 16 QPR2 on Pixel 9 and 10 series phones (9to5Google), it uses an on-device model to classify notifications into Promotions, News, Social, and Suggested — and the Promotions and News categories are enabled by default, filing matching notifications into a collapsed bundle in the shade’s silent section. The rollout is narrow today (recent Pixels, six countries, English), but the default matters: on the devices Google fully controls, a promotional push no longer buzzes, no longer banners, and sits folded until the user goes looking. Alongside it, on-device AI summaries compress conversation notifications.
The same OS cycle also built the opposite lane. Android 16’s progress-centric notifications (the Live Updates pattern) give genuinely live, user-tracked events — a delivery en route, an order status — persistent, elevated placement. Google’s 2026 releases have continued extending this live-content lane, though details of what ships beyond Android 16 are still settling and worth checking against current Android release notes before you build to them. The design intent is already unambiguous: content the user is actively tracking gets promoted; content the sender wants the user to notice gets organized out of the way.
Underneath the OS layer, Firebase Cloud Messaging’s long-standing per-device caps still apply — 240 messages per minute and 5,000 per hour to a single device, with sustained near-limit senders risking an abuse flag. Every system your company runs against the same app shares that budget.
iOS and Safari: a quieter kind of gate
Apple’s 2025–2026 story is less a crackdown than a controlled opening, because Apple built its gates in from the start: web push on iOS has always required the user to add your site to their Home Screen first (a deliberate high-intent filter, in place since iOS 16.4), and App Store policy has long constrained marketing push.
What changed:
- Declarative Web Push shipped in iOS/iPadOS 18.4 in March 2025 and reached the Mac in Safari 18.5 (WebKit). It lets you run web push from a standardized JSON payload with no service worker, and it removes the silent-push penalty for declarative messages because the payload itself guarantees a visible notification. Legacy service-worker push keeps working; the declarative format is the forward path Apple wants senders on.
- iOS 26 reportedly defaults Home Screen sites to opening as web apps, which widens the surface where iOS web push can run. We have only seen this documented secondhand so far; treat it as directional until Apple’s documentation is explicit.
- Policy is unchanged and strict. App Review Guideline 4.5.4 still requires that push not be required for your app to function, carry no sensitive personal data, and — for promotions or direct marketing — be sent only to users who explicitly opted in through consent language in your app’s UI, with an in-app opt-out. Abuse “may result in revocation of your privileges.”
For a retention team, the iOS takeaway is that Apple pre-filtered your audience for you. An iOS web push subscriber chose to install your site; an app push subscriber chose to opt into marketing. Both lists are small and high-intent — which means burning them with blast frequency is more expensive per subscriber than anywhere else.
RCS: reputation caps arrive on the newest channel
If you are adding RCS or WhatsApp to your mix — and for cart recovery and order updates, you should be evaluating messaging channels — Google has already installed the enforcement layer web push took six years to get.
Per Google’s RCS for Business documentation, every business sender (agent) carries a reputation — High, Medium, or Low — driven by user feedback and spam reports, and all new agents start Low. Reputation sets a traffic limit: the number of unique users the agent can initiate conversations with per rolling 28 days. Replies to conversations the user started are exempt. Enforcement went live for promotional agents in India on January 7, 2026, tightened on April 1, 2026 with a cross-agent cap on low-reputation senders, and the developer console now reports reputation level, traffic limit, spam trend, and unsubscribe reasons over 7- and 28-day windows.
At the consumer end, Google Messages has been grouping messages from unsaved senders under “Unknown senders” since mid-October 2025 and is rolling out verified checkmarks and standardized business branding — teardown-stage evidence on some details, but the direction matches everything else in this document. On RCS you do not get a grace period to build bad habits: reach is earned by engagement from message one.
Are you at risk? The self-audit {#self-audit}
Chrome and Google publish the factors but not the thresholds, so the honest audit is relative: measure whether you look like the sender these systems were built to stop. Run these eight checks against your last 30 days of sends. Every “no” is a finding. Several of these checks only mean something against outside numbers, so run them alongside our 2026 push notification benchmarks, where the percentile spreads for view rate and click-through show you what the median, p75, and p90 sender actually hits.
- Interaction ratio. Is your web push click-through rate meaningfully above the ecosystem’s sub-1% interaction baseline that Chrome cited when it justified auto-revocation? If your CTR has a zero after the decimal point, you are inside the profile Chrome is enforcing against.
- Volume vs. visits. Chrome’s first disruptive-site factor is pushes sent per time spent on site. Are you sending more notifications to a typical subscriber per week than that subscriber has sessions with you per week? A subscriber who visits monthly and gets pushed daily fails this ratio.
- Inactive tail. What share of your list has not clicked any notification in 90 days? If more than half your sends go to that tail, your aggregate engagement rate is being set by people who have already left — and the platforms grade the aggregate.
- Prompt discipline. Do you request notification permission on first pageview, before the visitor has done anything? Prompt-acceptance rate is both a quiet-UI enrollment criterion and a disruptive-site factor. Prompting after a demonstrated action (second pageview, add-to-cart, account creation) is the fix, and it shows up directly in your opt-in rate.
- Blast share. What percentage of your monthly send volume is untargeted list-wide blasts, versus notifications triggered by something the recipient did (cart abandoned, price dropped, item back in stock, order shipped)? Above roughly half blast, you are volume-heavy in exactly the pattern every mechanism on this page penalizes.
- Frequency caps and quiet hours. Do you enforce a per-subscriber cap across every campaign and system that can send — marketing, transactional, RSS, and any second tool? Android’s cooldown and forced grouping mean uncoordinated senders now visibly cannibalize each other on the same device.
- Copy honesty. Would any recent notification survive a skeptical reader’s “is this deceptive?” test — no fake urgency, no system-message cosplay, no bait gaps? Chrome’s on-device classifier is running that test on Android already.
- Unsubscribe trend. Is your unsubscribe rate per send flat or falling? On RCS it now feeds a reputation score with a hard traffic cap attached; on web push it is your early warning. Our guide to reducing push notification unsubscribe rates covers the diagnostic in depth.
Score yourself honestly. Five or more clean answers and the crackdown is mostly a tailwind for you — your competitors’ spray-and-pray is being throttled while your sends keep landing. Three or more findings and you should assume you are already losing reach you cannot see in a delivery report.
The compliance playbook: fixes that hold up
Every mechanism above measures the same underlying quantity — value per notification — so the fixes converge. These six moves, in priority order.
1. Cut the inactive tail before the platforms cut it for you. Build a lapsed segment (no click in 90 days), run one honest win-back sequence through it, then stop sending to non-responders. This is counterintuitive to teams that treat list size as the KPI, but the math is one-directional now: a dormant subscriber contributes zero revenue and actively degrades the engagement ratio Chrome scores you on. In PushEngage, dynamic segmentation maintains the lapsed bucket automatically, and because pricing counts active subscribers only, trimming dead weight cuts your bill rather than your reach.
2. Shift send volume from blasts to triggers. A cart-abandonment push, a price-drop alert, a back-in-stock notice — these earn clicks because the recipient’s own behavior scheduled them. Moving even half your monthly volume from calendar-driven blasts to triggered campaigns raises your interaction ratio on every factor Chrome measures, and it is where the revenue was anyway: triggered sends attribute to recovered carts and completed orders, not impressions. We made the full argument, with the campaign-class definitions and revenue-per-send math, in why the blast era just ended.
3. Segment whatever still gets broadcast. Some sends legitimately go wide — a storewide sale, a publisher’s breaking story. Wide is not the same as unsegmented. Splitting a broadcast by behavior, purchase history, or category affinity raises click-through on every slice and keeps each subscriber’s personal push-per-visit ratio defensible. Segmentation is now a deliverability requirement, not a personalization nicety — that post carries the full deliverability case.
4. Enforce one frequency cap across every channel and system. The Android 16 cooldown made this concrete: your CRM, your transactional layer, and your promo calendar share one attention budget on the device, whether or not they share a dashboard. Set a per-subscriber cap and quiet hours at the platform level, spanning web push, app push, and WhatsApp together, so four reasonable systems cannot compound into one abusive pattern. This only works if one segmentation engine sees every send — the strongest practical argument for consolidating channels rather than running one tool per channel.
5. Fix the opt-in moment. Move the permission prompt behind an action that signals intent, use a two-step prompt so the browser-level ask only fires on a yes, and accept the smaller, cleaner list. Prompt-acceptance rate feeds Chrome’s scoring at both ends — quiet-UI enrollment and the disruptive-site evaluation — and a consented list is also simply the list that clicks.
6. Make the copy survive a classifier. Plain claims, real urgency only when the deadline is real, sender identity obvious. On Android, an ML model reads your title and body before the user does. Honest copy was always better retention practice; now it is a delivery requirement too.
If you run these six on PushEngage, the honest summary of where the product helps: triggered campaigns, RFM and behavioral segments, cross-channel frequency caps, quiet hours, and per-notification revenue attribution are all built in, on plans that bill for active subscribers only — the pricing model happens to point the same direction the platforms now enforce. What no tool can do is decide to stop blasting; that part is policy, and it is yours.
FAQ
Why are my push notifications not being delivered in 2026? Check four suspects in order. First, Chrome auto-revocation: if your subscriber counts are quietly shrinking, low-engagement subscribers may be losing the permission via Safety Check. Second, Chrome rate limits: if sends to large lists suddenly take hours or your push service logs HTTP 429 responses, you have likely been classified disruptive. Third, Android presentation: on Android 16, delivery still happens but bursts are quieted and grouped, and on newer Pixels promotional pushes land in a silent bundle — delivered, unseen. Fourth, the boring causes that predate the crackdown: expired subscriptions, service-worker errors, and OS-level notification settings.
Did Chrome ban push notifications? No. Chrome rate-limits sites it classifies as disruptive (high volume, low engagement) and revokes permissions users demonstrably ignore. A sender whose notifications get clicked is unaffected by both mechanisms, and Google’s testing found lower-volume senders saw click rates rise.
What engagement rate keeps me safe from Chrome’s auto-revocation? Google has not published thresholds, and any vendor quoting you a safe number is guessing. The published facts: less than 1% of all notifications receive any interaction, and revocation targets the combination of very low engagement with high send volume. The defensible strategy is to hold your click rate well clear of that baseline and to stop sending to subscribers who have stopped responding.
Do the Chrome rate limits affect my whole account or just one site? Chrome’s evaluation language is per-site — messages, prompts, and engagement are all measured against “a site.” Senders using a push platform are evaluated on their own domain’s behavior, not their vendor’s aggregate. Google has not published guidance beyond that, so treat cross-domain specifics as unconfirmed.
What changed for push notifications in Android 16? Three things: notification cooldown (bursts progressively quieted for up to a minute, on by default, calls and alarms exempt), forced grouping of each app’s notifications, and — from the December 2025 QPR2 update on recent Pixels — the Notification Organizer, which files Promotions and News notifications into a silent collapsed bundle by default. Full mechanics in our Android 16 cooldown guide.
Does the crackdown apply to iOS? Apple’s constraints mostly predate it: iOS web push requires the user to add your site to their Home Screen, and App Store Guideline 4.5.4 requires explicit opt-in plus an in-app opt-out for marketing push. The 2025 change is Declarative Web Push (iOS 18.4 / Safari 18.5), a simpler, service-worker-free format with no silent-push penalty for declarative messages.
Are RCS business messages rate-limited too? Yes, by reputation. Google assigns every RCS business agent a High/Medium/Low reputation from user feedback and spam reports; low-reputation agents (including all new agents) face caps on unique users initiated per rolling 28 days. Enforcement is live for promotional agents in India as of early 2026, with reputation and spam-trend reporting in the developer console for everyone.
Is web push still worth it in 2026? For senders who trigger and segment, more than before: the throttled spray-and-pray traffic used to compete for the same notification shade you do. The platforms are strengthening the channel for the senders the channel was built for — and pushing the rest out.
Last updated and changelog {#changelog}
This hub is maintained as a living reference. Convention: the “Last updated” date changes only for substantive updates (a platform shipping, announcing, or documenting a change), not for copy edits. Each substantive update gets a changelog line with a source. If you are citing this page, cite it with its last-updated date.
- 2026-09-21 — Initial publication. Covers: Chrome Push API rate limits (Jan 2026), Chrome automatic permission revocation (announced Oct 2025), Chrome on-device ML notification screening (May 2025), Android 16 cooldown + forced grouping (June 2025), Android 16 QPR2 Notification Organizer (Dec 2025), Declarative Web Push (iOS 18.4 / Safari 18.5, 2025), RCS reputation-based traffic limits and spam-trend analytics (Jan–Apr 2026), Google Messages unknown-sender and verified-branding changes (from Oct 2025).
Something changed that we haven’t logged? The fastest way to get it in front of us is the chat widget on this page.
