Notification fatigue: how to measure it and how to reduce it

Notification fatigue is a subscriber who has stopped reading your notifications and has not told you yet.

That is the whole problem in one sentence. Nobody writes in to complain. The permission stays granted for a while. The send count looks the same as last month. What changes is quieter: the same story types get fewer interactions, new visitors decline the prompt more often, endpoints start failing, and the base shrinks most weeks even though nothing in the workflow changed.

If you want the short answer to "how do I reduce push notification fatigue": cap exposure per person rather than per campaign, and enforce the cap before the send rather than reading about it afterwards. The rest of this page is how to know whether you have a fatigue problem, and what to actually change.

What fatigue looks like operationally

Fatigue is not one number. It shows up as four different curves, and they move at different speeds.

The opt-out curve. Unsubscribes clustered in the hours after a send. This is the fastest signal and the one everybody already has. It undercounts badly, because most tired subscribers never click unsubscribe.

The permission-denial curve. The share of visitors who decline your prompt. This rises when your brand has taught the wider audience that your notifications are not worth it, and it is the one curve that damages acquisition rather than retention. The 2025 Web Almanac PWA chapter, from an HTTP Archive crawl in July 2025, reports that desktop users ignore notification prompts 78% of the time, with 16% acceptance on mobile. That is prompt behavior across a crawl, not your site, but it sets the baseline you are working against.

The ignored-streak curve. People who are still subscribed, still receiving, and have not interacted with the last five, ten, twenty messages. This is the real fatigue population and almost no push dashboard surfaces it. Chrome states that less than 1% of all notifications receive any interaction from users, which tells you how large this group is across the web as a whole.

The silent-removal curve. Subscriptions that disappear without an unsubscribe click. Some are dead devices and cleared browser data. Some are the browser deciding for the reader.

That last one is the change that turned fatigue from a courtesy question into a delivery question.

The browser is now part of your fatigue policy

Three things happened, and they are already in effect. None of this is a forecast.

In October 2025 Chrome shipped automatic removal of notification permission for sites a user has not interacted with recently, when engagement is very low and notification volume is high. Chrome informs the user. The user can re-grant permission in Safety Check or on the site, or turn auto-revocation off. Installed web apps are not revoked by this feature. It applies to desktop and Android.

In January 2026 Chrome began rolling out Push API rate limits for sites that send many notifications with little site engagement. A site judged disruptive is limited to no less than 1,000 messages per minute, and excess requests receive HTTP 429. The daily factors Chrome names are push messages per time on site, permission prompts per time on site, and engagement measured as site engagement score and foreground minutes. Escalation runs one day, then seven days, then fourteen; the state resets after 42 consecutive non-disruptive days. This applies to the Push API only, not to the Notifications API. Chrome states that nearly all websites will be unaffected.

In August 2026 Chrome Security described the whole stack as a multi-layered defense: auto-revocation for low engagement and for sites with repeated suspicious-notification warnings, behavioral detection of coordinated abuse networks, FCM server-side rate limits, and a streamlined permission model including one-tap unsubscribe on Android. Users review revoked permissions in Safety Hub.

Read the rate-limit factor list again, because it is the most useful sentence any browser vendor has published on this topic. The factors are ratios. Not messages per day, but messages per unit of attention you actually earned. A site that publishes constantly and holds readers on page can carry volume that would flag a site with the same send count and no engagement.

What you cannot do is reverse-engineer the threshold. Chrome does not publish its internal scoring, and anyone who tells you they mirror it is guessing. Treat the browser as a hard outer boundary and set your own policy well inside it.

How to measure fatigue on your own list

This is a procedure, not a benchmark. It uses data you already have in any push provider plus your analytics, and you can have the first version running in a week.

1. Fix the denominator

Define an active subscriber explicitly: a valid endpoint that has received at least one message in the last 30 days and has not returned a permanent failure. Write the definition down. Most arguments about list size are really arguments about two different denominators.

2. Build a per-send ledger

For every send, record: eligible audience, delivered, interactions, opt-outs within 24 hours, and endpoints removed as invalid within 24 hours. Five numbers per row. Your provider has four of them; the fifth usually needs the delivery error log.

3. Build a per-subscriber exposure counter

For each subscriber, keep messages received in the last 7 days and consecutive messages without an interaction. These two integers are the entire fatigue model that matters, and they are what most platforms do not keep.

4. Cohort by ignored streak

The cohort boundaries are a starting point for a test, not a measured benchmark. What matters is that you split the list at all, because a list-wide average hides the shape completely.

5. Track net list movement weekly

New permissions granted, minus unsubscribes, minus invalid endpoints removed. Plot it weekly against send volume. If the line is negative in weeks where volume is high and positive in weeks where volume is low, you have your answer and you have it in a form an editor will accept.

One honest caveat: no browser tells you which removal was an auto-revocation. You see the endpoint return a permanent failure, and the reason is inferred, not reported. Do not present inferred causes as measured ones.

What actually reduces fatigue

Per-subscriber frequency ceilings. A site-level cap of eight sends a day says nothing about the person who received all eight. Cap what one person receives in a day and in a week. This single change usually does more than everything else on this list.

Topic and story dedupe. The same story reaching one reader twice under two headlines is the most avoidable form of fatigue there is. Deduplicate on the underlying content, not on the campaign row, and add a cooldown per topic so a running story does not consume a reader's whole week.

Quiet windows. Routine sends respect a local send window with a real timezone. Night delivery buys a small amount of reach and a large amount of resentment, and it is the fastest way to teach someone to turn the whole channel off.

Resting on ignored streaks. Stop sending to people who have ignored the last several messages, and keep them subscribed while you do it. A rest is a decision. It is not a failed campaign, and it protects the permission you already paid to acquire.

A value floor. Some sends should not happen at any frequency. If the content is weak, the correct number of recipients is zero, and a cap with room left in it is not a reason to fill it.

An explicit override. Breaking news needs to bypass the policy. Make that a named, logged decision rather than a general exception, otherwise every story becomes breaking news within a month.

Fatigue belongs before the send, not in a report

Most push tooling puts fatigue in the analytics tab. You send, and then you learn what it cost. By then the permission is gone and the acquisition cost of replacing it is real.

The version that works treats fatigue as a policy the send has to pass. Per-subscriber caps, minimum spacing, quiet hours, dormancy rules and a value floor are evaluated at send time, the ineligible recipients are removed before delivery, and the reason is recorded so somebody can argue with it later. That last part matters more than it sounds. In a newsroom, restraint loses every argument it cannot show numbers for.

If you want to write this down in a portable form, the Open Attention Policy is an open JSON format for exactly these fields, with an MIT-licensed validator. You can use it against any provider, including one that is not ours.

Limitations and browser caveats

• Apple's platforms behave differently. Declarative Web Push shipped in Safari 18.4 on 31 March 2025 for Home Screen web apps on iOS and iPadOS, using a standardized JSON payload and no installed service worker. Your interaction signals from those subscribers are not identical to Chrome's, so do not pool them into one fatigue model without checking.
• The Chrome rate limits apply to the Push API, not the Notifications API. Locally triggered notifications are a different surface.
• There is no cross-browser API that tells you why a subscription ended. Silent removals are inferred.
• Every browser number on this page comes from Chrome, WebKit or the HTTP Archive, dated above. EngageNudge has not published a fatigue benchmark of its own, and we are not going to invent one to make a page look authoritative.

How EngageNudge handles this

EngageNudge evaluates the fatigue policy before a Nudge goes out, not after. Daily and weekly exposure limits, minimum time between Nudges, ignored-streak signals, dormant-reader protection, topic-specific cooldowns, quiet hours and an explicit breaking-news override are all inputs to a single send or skip decision, and a skip is recorded as a decision rather than an error.

A public reputation score and full churn forensics are on the roadmap and are not live today. What exists now is the policy layer and the audience view behind it.