Web push notifications usually don’t show because permission is blocked, the operating system is silencing the browser, the service worker isn’t registered or handling push events, the subscription has expired, or the VAPID keys don’t match. On iPhone, the site must also be added to the Home Screen. Check those first; they cover most cases.
When push isn’t working, I don’t start with the server. I start at the visitor’s screen and work backwards, because most failures happen at the browser or operating system layer, not in the sending code. Below are the 10 fixes I check, in that order, with what to look for in each one.
Why are my website push notifications not showing?
Website push notifications fail at one of three layers: the device (permission and OS settings), the browser (service worker and subscription), or the sender (keys, payload and response codes). This table maps symptoms to the likely layer.
| Symptom | Likely layer | Fix to check first |
|---|---|---|
| No prompt ever appears | Browser | Fix 1 and Fix 5 |
| Prompt accepted, nothing arrives | Device or browser | Fix 2, Fix 3, Fix 6 |
| Worked before, stopped for everyone | Sender | Fix 7 and Fix 8 |
| Works on desktop, not on iPhone | Device | Fix 4 |
| Generic “site updated in the background” message | Service worker | Fix 6 |
| Server shows errors on send | Sender | Fix 8, Fix 9, Fix 10 |
Fix 1: Is notification permission blocked in the browser?
If permission is set to Block, the browser silently ignores your site’s push messages and won’t show the prompt again. In Chrome, click the site settings icon left of the address bar and check Notifications. Firefox, Edge and Safari have similar per-site settings.
You can also check in code: Notification.permission returns “granted”, “denied” or “default”. Once a visitor denies, only they can change it in browser settings. So ask at a sensible moment, as covered in my guide to enabling push notifications.
Fix 2: Is the operating system silencing the browser?
The operating system can hide notifications even when the browser allows them. Check these settings on the device:
- Windows: Settings, System, Notifications. Make sure the browser is allowed and Do not disturb is off.
- macOS: System Settings, Notifications. Allow the browser, and check that a Focus mode isn’t active.
- Android: Settings, Apps, your browser, Notifications. Also check battery saver settings, which can delay delivery.
This is the fix people forget most often, because everything looks correct inside the browser.
Fix 3: Is the browser running?
On desktop, the browser generally needs to be running, even in the background, to receive web push. If Chrome or Firefox is fully closed, messages wait at the push service and arrive when it opens, as long as the message’s time to live (TTL) hasn’t expired. A TTL of 0 means “deliver now or never”, so offline devices miss it.
Fix 4: On iPhone, is the site added to the Home Screen?
On iPhone and iPad, web push only works for web apps added to the Home Screen, from iOS and iPadOS 16.4. A regular Safari tab can’t receive push. The site also needs a web app manifest, according to Apple’s WebKit announcement. See iPhone push notifications without an app for the full steps.
Fix 5: Is the site on HTTPS and is the service worker registered?
Service workers and the Push API only work on HTTPS, with localhost allowed for testing. In Chrome DevTools, open Application, then Service workers, and confirm your worker shows as activated with the right scope. A 404 on sw.js, a worker in a subfolder, or a redirect on the worker URL will all stop push. My guide to setting up a service worker for web push explains scope in detail.
Fix 6: Does the push handler actually show a notification?
Your service worker must call showNotification() inside the push event, wrapped in event.waitUntil(). If it doesn’t, Chrome may show a generic notification saying the site has been updated in the background. A JavaScript error in the handler, such as parsing a non-JSON payload with event.data.json(), stops the notification too. Use the Push button in DevTools to test the handler directly.
Fix 7: Has the subscription expired or been replaced?
Subscriptions expire or get replaced when users clear site data, reinstall the browser, or when another push tool registers its own service worker on the same scope. Push services then return 404 or 410 for that endpoint. Your sender should remove those subscriptions and stop sending to them, as described in the Web Push protocol, RFC 8030.
If notifications stopped for everyone right after you installed a second push plugin, a service worker conflict is the likely cause.
Fix 8: Do the VAPID keys match the subscriptions?
Every subscription is tied to the VAPID public key used when it was created. If you change or regenerate your key pair, sends to old subscriptions fail with authorisation errors. Keep your keys stable and back them up. For background, read what VAPID keys are and whether you need them.
Fix 9: Is the payload too large or badly formed?
Push services reject payloads over about 4 KB, often with a 413 response. Keep the payload to the title, body, icon, image URL and click URL, and load anything larger from your server. Also make sure the payload format matches what your service worker parses.
Fix 10: Are you being rate limited or flagged as spam?
Sending too fast can trigger 429 Too Many Requests responses, so respect the Retry-After header and spread big sends through a queue. Separately, Chrome can flag sites with abusive notification patterns. My post on Chrome’s possible spam notification update covers what that means for publishers.
How do you read push service error codes?
Push services reply to every send with an HTTP status code, and those codes tell you which fix applies. Here are the common ones from the Web Push protocol.
| Status code | Meaning | What to do |
|---|---|---|
| 201 Created | Accepted by the push service | Nothing; delivery is now up to the device |
| 400 Bad Request | Malformed request or headers | Check your library and headers |
| 403 Forbidden | VAPID authorisation failed | Check keys and the VAPID subject (Fix 8) |
| 404 or 410 | Subscription expired or gone | Delete the subscription (Fix 7) |
| 413 Payload Too Large | Payload over the limit | Shrink the payload (Fix 9) |
| 429 Too Many Requests | Rate limited | Slow down and honour Retry-After (Fix 10) |
A 201 only means the push service accepted the message. If the notification still doesn’t appear, go back to Fixes 1 to 6 on the device.
Where does LaraPush fit?
LaraPush is a self-hosted push panel, so subscriptions and send logs sit on your own server. Its analytics show sent, delivered and clicked counts per campaign, which helps you see whether a problem is at the sending side or the device side. It also includes server and queue monitoring. Trade-offs: you run a VPS, a licence covers one server, and there’s no free plan. See features, the setup guide and pricing, or compare options in the best push notification services and tools.
Frequently asked questions
The most common causes are blocked browser permission, operating system settings such as Do not disturb or Focus, a service worker that isn’t registered or doesn’t call showNotification(), expired subscriptions, and changed VAPID keys. On iPhone, the site must be added to the Home Screen on iOS 16.4 or later.
iPhone and iPad only support web push for web apps added to the Home Screen, from iOS and iPadOS 16.4. A normal Safari tab can’t receive push, and the site needs a web app manifest. The user must add the site to the Home Screen, open it and then allow notifications.
Two push tools that register service workers on the same scope can overwrite each other. The newer worker takes over, and subscriptions made with the old tool stop receiving messages. Remove one tool, or make sure only one service worker handles push on your site.
A 410 Gone response means the push subscription no longer exists, usually because the user cleared site data, unsubscribed or reinstalled the browser. Your server should delete that subscription and stop sending to it. A 404 response is treated the same way.
On desktop, the browser usually needs to be running, even in the background. Messages wait at the push service and arrive when the browser opens, unless the time to live has expired. On Android, push can arrive with the browser closed, but battery saver settings may delay it.
