Push Notification Reliability: What Delivery Really Means

Push notifications are reliable enough for most product messaging and not reliable enough to be your only channel for anything critical. A successful API response means a platform service accepted your message. It does not mean a person saw it. If an alert matters, such as a cooling fault, a safety incident or a failed login approval, you have to design for the gap between accepted and acknowledged.

This guide explains where that gap comes from, how Apple’s and Google’s services differ in practice, what to measure instead of a single delivery rate, and how to build an escalation path that does not depend on one phone being awake.

TL;DR

• Accepted is not delivered. Both Microsoft’s notification documentation and Firebase treat provider acceptance as a checkpoint, not proof of display.
• Expiry must match meaning. Set a short lifespan for alarms so a stale alert never arrives hours late looking current. Use collapse keys only when the newest state replaces the old one.
• Measure five states separately: sent, accepted, delivered, displayed, acknowledged.
• Critical events need a fallback. Treat push as one channel in a policy, with a durable event record and an acknowledgement timeout that triggers another route.
• Permission is part of reliability. Irrelevant notifications train users to block them, and a blocked channel delivers nothing.

Table of Contents

• What “reliable” means for a push notification
• APNs vs FCM: how the two paths differ
• Where messages actually get lost
• What about push notification delivery rates?
• Permission quality is a reliability control
• Designing critical alerts that survive failure
• A warning about push-based authentication
• Our perspective
• How PODTECH can help
• FAQ
• Sources

What “reliable” means for a push notification

A push message passes through several hands. Your application back end calls a provider API. The provider hands the message to Apple’s APNs or Google’s FCM. That platform service holds it until the device is reachable. The operating system then decides whether to show it. Each hop can delay or drop the message for a legitimate reason.

Microsoft’s guidance says delivery is generally within seconds when platform services are healthy, but messages can still be delayed or dropped. The causes it and other platform documentation list are ordinary:

• notification permission switched off or revoked
• Focus or Do Not Disturb modes
• no connectivity, or aggressive power management
• invalid tokens and uninstalled apps
• operating system policy and throttling
• provider-side expiration

So the honest answer to how reliable push notifications are is: very good at the median, unpredictable at the tail, and never guaranteed end to end. For a retail promotion, the tail does not matter. For infrastructure alerts it is the only thing that matters.

Five events that are often confused

Teams often report a single delivery rate that quietly mixes these states:

The first two are cheap and almost always succeed. The last two are the ones that protect your operation. Instrument all five and you can see exactly where a missing alert disappeared.

APNs vs FCM: how the two paths differ

Most enterprise apps ship on both iOS and Android, so you depend on both services. They share a store-and-forward model but behave differently around lifespan, ordering and storage.

Message lifespan and expiry

Both services hold a message when a device is offline. FCM lets you set a time to live from 0 to 2,419,200 seconds, which is 28 days. A value of 0 discards anything that cannot be delivered immediately, and without a TTL the default storage period is four weeks. Firebase also notes that Android devices not connected to FCM for more than a month can have their stored messages discarded at once.

Apple offers the equivalent through an expiration value, and FCM can pass it to Apple devices through the apns-expiration header. Apple’s notification programming guide documents expiration as the mechanism that causes stale notifications to be discarded.

The practical rule: a persistent alarm must not arrive hours later as if it were current. Choose the expiry by asking how long the message stays true.

Collapsing, storage limits and ordering

On Android, FCM distinguishes collapsible from non-collapsible messages. Collapsible messages suit cases where only the latest state matters, such as telemetry or status synchronisation. Non-collapsible messages suit events where every message matters, but there are limits to plan around:

• FCM stores at most 100 non-collapsible messages for an offline device. Beyond that, stored messages can be discarded and the app should perform a full synchronisation.
• At most four different collapse keys can be held per registration token at one time.
• FCM does not guarantee message order.

That last point catches teams out. If alarm cleared can overtake alarm raised, your app will show the wrong state unless it reconciles against the server.

One path, two sets of constraints

Using Firebase on iOS does not remove Apple from the chain. On Apple platforms, FCM still delivers through APNs, and Firebase documents payloads of up to 4096 bytes through its APNs interface. A cross-platform abstraction does not erase token lifecycle problems or Apple’s background-delivery policies. Test Android and Apple behaviour separately, with separate credentials and separate failure cases.

Why iOS often feels less reliable

Developer complaints that iOS is less dependable than Android are common, and many trace back to the factors above: background delivery rules, silent-push throttling, and users with Focus modes enabled. Delays also happen on the platform side. One Apple developer forum report describes pushes handed to APNs in under five seconds that sometimes took up to five minutes to reach devices. That is one anecdote, not a benchmark, but it shows why you should log timestamps at your own boundary and at the device.

Where messages actually get lost

In our experience of mission-critical systems, delivery failures cluster in four places. Check these before blaming a provider.

1. Stale or invalid tokens. Uninstalls, reinstalls and OS restores invalidate tokens. If your back end never prunes them, your delivery rate looks worse than it is, and real users may be missing from the list.
2. Offline devices and expiry. A phone in a basement plant room or a lift lobby may be unreachable for the whole window of a short TTL. That is correct behaviour for a time-critical alarm, but you need a second channel.
3. Burst load on the sender. In large bursts, sender-side connection, bandwidth and compute capacity can create delay. Load testing and backpressure belong in the reliability plan, not in an optimisation backlog. Some providers also cap request rates per project, and requests above the cap fail until the rate falls.
4. User-controlled settings. Permissions, notification summaries and quiet modes are outside your control. You can only influence them through relevance and trust.

What about push notification delivery rates?

There is no universal figure to benchmark against. Third-party tables of API response times and error rates exist, but they measure how quickly a provider API answers, not whether an end user saw the message, and their methodology and traffic mix are usually proprietary. Treat them as directional.

A better target is internal and tied to consequences. Define, per message class:

• the maximum acceptable time from event to display
• the share of messages that must be acknowledged within that time
• the action taken when they are not

Then report on those numbers, split by platform and by app version. A single blended rate hides the fact that one OS version may be failing.

Permission quality is a reliability control

A notification that the user has blocked will never display, whatever your infrastructure does. MDN reports that some studies have found as many as 60% of push notifications blocked on the web, and advises asking for permission only after users understand the value. It adds that every notification should be useful and time-sensitive, with an easy way to opt out.

For enterprise apps the lesson is direct. If your operations app sends routine noise, the on-call engineer will mute it, and the one alert that matters goes unseen. Separate alert classes into distinct notification channels, keep informational traffic out of the critical channel, and let people tune the rest.

Designing critical alerts that survive failure

For life-safety, outage, security or operational escalation, push should be one channel inside a delivery policy. A workable pattern:

1. Write the event to a durable store first. The server record is the truth. The notification is a pointer to it.
2. Send with an expiry that matches the event. Use a short TTL for alarms, collapse keys for status updates that supersede each other.
3. Require acknowledgement. The app reports back when the user sees or accepts the alert.
4. Escalate on a timeout. If there is no confirmed receipt or acknowledgement in the defined window, trigger a fallback such as SMS, email or a voice call. Fallback guidance from a messaging platform describes the same idea: trigger it from confirmed receipt or a defined timeout.
5. Prevent duplicates. Use message IDs, expiry and channel-aware state so a recovered device does not replay old alarms.
6. Synchronise on reconnect. When the app opens, it fetches current state from the server instead of trusting a queue of missed pushes.

Note that delivery semantics differ by service. One provider’s documentation describes an at-most-once model, while others describe at-least-once handoff to Apple and Google. Your system must therefore define whether it counts API acceptance, provider receipt, device receipt, display or acknowledgement, and tolerate rare duplicates or gaps.

A warning about push-based authentication

Reliability has a security twin. Push approval for multi-factor authentication is convenient but is not phishing-resistant. CISA guidance, as summarised in 2022, urges organisations to adopt phishing-resistant MFA and number matching in their MFA apps. Number matching reduces prompt-bombing fatigue attacks, but it remains vulnerable to phishing. Origin-bound FIDO/WebAuthn or PKI-based methods are the stronger control.

For privileged, financial and critical-infrastructure accounts, prioritise passkeys or hardware security keys. Where push approval has to stay, require number matching. Speak to your security team or identity provider before changing policy, because the right mix depends on your user base and regulatory obligations.

Our perspective

We build software for places where an unseen alert has a cost: datacenter floors, building systems and construction sites. That shapes how we treat notifications.

We never treat a push as the record of an event. The record lives in the platform, and the phone is one way to learn about it. In monitoring work, that means alarms are stored, timestamped and acknowledged server-side, and the mobile app reconciles against that state every time it opens.

We also separate message types by intent. Telemetry that supersedes itself is collapsed. Safety events and escalations are not, and they carry a defined acknowledgement path. Where a site manager has to know about a hazard now, the design assumes the first channel can fail and plans the second before launch.

The most common mistake we see is measuring the wrong thing. A dashboard that shows 99% delivered while nobody can say how many people saw the alert gives false comfort. Start with the question what happens if this message never arrives and build backwards.

— Harry

How PODTECH can help

If you are building or hardening alerting for an operational app, our team designs and builds custom mobile apps for iOS and Android, including the server-side event stores, acknowledgement flows and fallback channels described above. For sensor-driven alerting in facilities, see how we approach generator monitoring, and browse our product line, including LifeSafety.ai for construction site safety. To discuss a project, start from podtech.com.

FAQ

Are push notifications guaranteed to arrive?

No. Platform documentation describes delivery as best effort. A successful API response means the message was accepted, and device permissions, connectivity, power management, expiry and OS policy can still prevent or delay display. Anything critical needs a fallback channel.

Is FCM or APNs more reliable?

Neither is reliably better in every case, and on Apple devices FCM still sends through APNs. They differ in controls: FCM offers a TTL up to 28 days, collapse keys and a 100-message storage limit for offline Android devices, while Apple uses an expiration value. Test both with your own traffic and measure display, not just acceptance.

How should I set expiry for urgent alerts?

Match it to how long the alert stays true. For strictly time-sensitive events, a TTL of 0 on FCM discards messages that cannot be delivered immediately, so a stale alarm never appears. Pair that with a server-side record so the app can show current state on reconnect.

Is push-based MFA safe?

It is safer when paired with number matching, but it is still open to phishing. CISA recommends phishing-resistant FIDO/WebAuthn or PKI-based authentication. For privileged and critical-infrastructure accounts, use passkeys or hardware security keys where you can.

Sources

• Microsoft Learn: Diagnose dropped notifications in Notification Hubs
• Firebase: Set the lifespan of a message
• Firebase: Non-collapsible and collapsible messages
• Firebase: Get started on Apple platforms
• Apple: Local and Remote Notification Programming Guide
• Apple Developer Forums: Delay in APNS notification delivery
• MDN: Web Push API notifications best practices
• SC Media: CISA on phishing-resistant MFA
• Fallback messages across channels

Recommended

• Map MQTT QoS to Risk for IoT Engineers: 3 Levels and When to Use Each
• Prevent Bricked Fleets: 3 OTA Firmware Update Controls for Engineers
• Why Custom DCIM Software Outperforms Off-the-Shelf Solutions