A lot of times you may see a lag in receiving notifications or sometimes there might be cases where the notification is never received. Below are the probable reasons for the same:
When a subscriber clears cookie and other site data in Chrome, the service worker gets uninstalled along with the browser key. This results in the website not being able to push notifications to that subscriber.
If a subscriber changes the notification permission from ‘allow’ to ‘block’, no notification would be sent nor would the subscription prompt appear again to ask for consent once again.
If the permission is changed to ‘remove’, the subscription prompt would appear again on the website upon reload.
Some custom versions of Android have a power saving setting that delays or ignores a notification. Some enter a low power mode when their battery is nearing exhaustion which also leads to delayed notifications.
Then again, there are some wifi routers that sometimes close off the connection to the browser servers. After the device re-opens this connection later, all notifications are received in a delayed state. Also, in a lot of corporates, the firewall rejects the incoming packets due to security settings.
There are certain devices of Xiaomi, MI, Lenovo, Asus and even Motorola which are known not to receive notifications when the application is running either in the background or foreground.
When subscribers are not connected to the internet for a long time, the connection to the browser servers is lost. These servers maintain an idle socket connection to ensure that this connection stays active. Devices send a heartbeat every 15 minutes on wifi and every 28 minutes on mobile data. If this heartbeat is not received, the server considers the connection to be broken and attempts to re-establish it. In this case, the notification won't be marked either dormant or delivered.
TTL Expiration before Delivery
If the browser server is unable to connect to a device within the TTL (time to live) of a notification, it won’t get delivered at all.