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.

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 in delayed notifications.

Then again, there are some wifi routers that sometimes close off the connection to the FCM 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 GCM servers gets lost. GCM maintains an idle socket connection from an Android device to Google’s servers. To ensure that this connection stays active, devices send a ‘hearbeat’ every 15 minutes on wifi and every 28 minutes on mobile data. If this ‘heartbeat’ is not received, Google considers the connection to be broken and attempts to re-establish it. In these cases, GCM is unable to deliver the notification nor mark them as dormant.

TTL Expiration before Delivery

If the GCM is unable to connect to a device within the TTL (time to live) of a notification, it won’t get delivered at all.