Increasing web push notification value with rate limits

Rob Kochman
Rob Kochman

Published: January 6, 2026

Beginning this month, Chrome will start rolling out Push API message rate limits for sites that send many notifications without much site engagement. This post explains the change, and the sites likely to be impacted by it.

The open web is a powerful platform for connecting with users, and the Push API has been a transformative part of that. In conjunction with the Notifications API, the Push API enables sites to deliver timely notifications even when the website is not running in the browser. This allows for a persistent and valuable connection between users and the sites they care about most.

However, as is often the case with powerful technology, there's a potential for misuse. Many of us have experienced it: a website that bombards us with a constant stream of notifications that aren't relevant or valuable. This can be due to issues such as a website changing its behavior since the permission was granted or a user getting tricked into accepting a permission request. Such unwanted notifications disrupt a user's workflow and can lead to a negative perception of notifications and the web altogether. We believe that the power of push notifications should be matched with a responsibility to use them wisely.

Our ongoing commitment to a better notification experience

We've worked hard to give users more control and to tackle notification spam head-on. In Chrome 80, we introduced quieter notification permission prompts, which shows a more subtle prompt for sites with low acceptance rates or for users who frequently block notification requests. More recently, for Chrome on Android, we've begun to use on-device machine learning to identify and warn users about potentially spammy or malicious notifications, which helps protect users from phishing attempts and other harmful content without compromising privacy. We also automatically revoke notification permissions from sites that Google Safe Browsing identifies as engaging in abusive behavior. Lastly, in October we announced that Chrome will automatically remove notification permission on a per-user basis for sites a user hasn't interacted with recently. These are just a few examples of our ongoing commitment to creating a safer and more pleasant notification experience for everyone.

A new layer: Push API rate limits

To further protect Chrome users from overwhelming notification volume and to ensure that notifications remain a useful tool for everyone, we'll be introducing a rate limiting mechanism for the Push API based on user engagement. Our goal is to create a better web, where users are in control and developers are empowered to build meaningful connections. This change is designed to curb abusive notification practices while having no impact on legitimate websites.

How it works

Initially, our determination for rate-limiting a site will be based on three key factors, which are calculated daily:

  • The number of push messages a site has sent per time spent on a site.
  • The number of permission prompts shown per time spent on the site.
  • The level of engagement that user has with the site (based on the site engagement score and number of foreground minutes).

When a site is identified as sending a high volume of notifications with very little user engagement, we will consider it disruptive and will limit its ability to send messages to a value no less than 1000 per minute. Requests above that limit will result in an HTTP 429 response.

To prevent disruptive sites from quickly cycling between disruptive and non-disruptive behavior, the logic to remove the rate-limit is more complex:

  • After the first day of disruptive behavior, the rate limit will apply for one day.
  • After the second day of disruptive behavior, the rate limit will apply for seven days.
  • After the third and subsequent day of disruptive behavior, the rate limit will apply for 14 days.
  • The count will reset after 42 consecutive days of non-disruptive behavior.

Though this describes our initial approach, the specifics of this calculation may evolve over time as the ecosystem evolves, to best serve both users and the developer community.

Will this impact my site?

It's important to emphasize that this change will only affect the Push API. Sites will still be able to send notifications while open using the Notifications API.

Nearly all websites will be unaffected by this change. This initiative is targeted at a small number of sites that are sending an excessive number of low-value notifications. For the broader developer community that is focused on sending timely, relevant, and engaging notifications, this change will help to preserve the integrity and effectiveness of this powerful communication channel.

We believe this is a necessary step to ensure a healthy and sustainable future for web notifications. By encouraging a more thoughtful and user-centric approach, we can collectively create a better notification experience for everyone on the web.