Push notification frequency: how often should a news site send?

The honest answer is that it depends, and the useful part is what it depends on.

There is no publishable number for how often a news site should send push notifications. Anyone quoting you "two to five per day for publishers" is either repeating a vendor blog with no named sample or averaging over sites that have nothing in common with yours. What does exist, and what you can act on today, is a ceiling the browser enforces, a budget your readers hold, and a floor set by what an individual send is actually worth.

Two frequencies that get confused

Almost every unproductive argument about push frequency comes from mixing these up.

A newsroom sending 20 times a day where a typical reader receives two is a completely different product from one sending four where every reader receives all four. The second one is more aggressive, and the send count on the dashboard says the opposite.

So the question "how often should we send" is really two questions, and only the second one has a fatigue answer. Set the per-subscriber number first. Site frequency then becomes an editorial and targeting problem rather than an audience-trust problem.

The ceiling Chrome actually enforces

This part is not opinion, and it is not a forecast. It has been in effect since 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, and the state resets after 42 consecutive non-disruptive days. It applies to the Push API only, not the Notifications API. Chrome states that nearly all websites will be unaffected.

Separately, since October 2025 Chrome automatically removes 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, who can re-grant permission in Safety Check or on the site, or turn auto-revocation off. Installed web apps are not affected. Desktop and Android.

Two things follow from that, and both change how you should think about the number.

First, the enforced measure is a ratio, not a count. Push messages per time on site. Permission prompts per time on site. A site whose readers stay and come back has more room than a site with the same send count and no engagement, which means "how many per day" is the wrong unit and "how many per unit of attention we earned" is the right one.

Second, the enforcement is per site, but the auto-revocation is per person. A frequency that is fine in aggregate can still be quietly stripping permissions from your least engaged third.

You cannot compute your position against Chrome's threshold. The internal scoring is not published, and modelling it is guesswork. Set your own ceiling well inside theirs and stop trying to find the edge.

Why this page has no category benchmark table

I could put a table here with a row per vertical and a plausible number in it. It would rank. It would also be made up.

We publish browser and market facts only from a dated claim register with a primary source, and there is no approved source for "news sites send X notifications per day". The vendor blogs that publish opt-in rates and send frequencies by country do not name a denominator, do not describe a sample, and mostly measure their own customer base. Technology-detection snapshots tell you which sites run a push platform, not how often those sites send.

We run our own crawl work on Nordic publishers. When it produces frequency figures, the method and the sample will be published before the numbers are. Until then this page gives you a framework, and you get to keep your own result.

A framework for finding your number

1. Start from the per-subscriber ceiling

Pick a maximum a single person can receive in a day and in a week. Choose it deliberately, write it down, and make it the constraint that everything else works inside. If the newsroom pushes back, the number is doing its job.

2. Set a value floor before you set a count

Some sends should not go out at any frequency. Define what a story needs to clear before it becomes a Nudge: a threshold on content confidence, a story-type rule, whatever your desk will accept. A cap with room left in it is not an instruction to fill it.

3. Separate routine from urgent, explicitly

Routine sends live inside the cap, respect quiet hours and skip dormant subscribers. Urgent sends may break the cap through a named override that is logged. If the override is not logged, everything becomes urgent within a month. I have watched that happen.

4. Steer on quality per send, not sends per day

The number worth putting on a wall is what one send costs and returns, not how many you managed.

A workable version: for each send, take interactions per 1,000 delivered, and subtract opt-outs and invalid endpoints per 1,000 delivered. That gives you a net figure per send that goes down when you push a weak story to a broad audience, which is exactly the behavior you want the metric to punish. This is our framework, not an industry standard. Change the weights if your economics differ, but keep the subtraction, because a metric without a cost term will always argue for sending more.

5. Move one step at a time and hold

Change the per-subscriber cap by one, hold it for two to four weeks, and watch net list movement: new permissions granted minus unsubscribes minus invalid endpoints. One variable, long enough to see the list respond. Frequency experiments that run for four days measure the news cycle, not your policy.

The part that is specific to publishers

Every journalist wants their story pushed. That is not a flaw in the newsroom, it is the newsroom working correctly, and each individual request is reasonable on its own terms.

The problem is that the person who owns the audience is arguing against a stack of individually reasonable requests, and the only number in the room is the click count from the last send. Click counts always argue for sending more. Nothing on the standard dashboard shows what the send cost in subscribers, so restraint arrives with an opinion and loses.

That is the case for keeping a per-send ledger even before you change any policy. Clicks, opt-outs, invalid endpoints, and net list movement for the week, on one row per send. The argument becomes arithmetic, and arithmetic is much easier to win with.

Limitations and browser caveats

• Chrome's rate limits apply to the Push API, not the Notifications API, and Chrome states nearly all sites are unaffected. Do not use them to frighten anyone into a number.
• Apple's platforms differ. Declarative Web Push shipped in Safari 18.4 on 31 March 2025 for Home Screen web apps on iOS and iPadOS. Frequency tolerance and the signals you get back are not identical to Chrome's.
• Browser mix changes what any of this means for you. StatCounter reported worldwide browser share for July 2026 as Chrome 68.22% and Safari 16.47%; Europe as Chrome 60.71% and Safari 18.67%; Sweden as Chrome 57.37% and Safari 24.75%. A frequency policy tuned to Chrome behavior covers a different share of your list in different markets.
• No number on this page is an EngageNudge measurement. The framework is ours, the browser facts are Chrome's and WebKit's, and the crawl figures are StatCounter's, all dated above.

How EngageNudge handles frequency

Frequency in EngageNudge is a policy the send has to pass rather than a field on the campaign. Per-subscriber daily and weekly caps, minimum spacing between Nudges, quiet hours, dormancy rules and a low-value send gate are evaluated before delivery, and a Nudge that fails them is skipped with the reason recorded.

Holdouts sit underneath that, so the question "did the extra send actually bring anyone back" has an answer that is not the click count.