A leak sensor detects water at 3:14 in the morning. The phone on the nightstand buzzes at 3:14 and forty seconds. Between those two moments sit four network hops, two authentication handshakes, and a delivery service neither you nor your customer controls — and any of them can silently swallow the message. Push notification is the most visible thing a connected product does and the part founders budget the least engineering for.
The Actual Delivery Chain
Nothing on a phone listens directly to your hardware. The path is fixed and it has four segments.
- Device to cloud. The product publishes an event over a persistent connection, typically MQTT, or wakes a cellular radio and posts once. A maintained MQTT session delivers in tens of milliseconds; a device that has to wake, associate to Wi-Fi, and open TLS spends three to eight seconds before it says anything, which is the tradeoff examined in MQTT versus HTTP for IoT.
- Cloud logic. Your backend decides whether this event deserves a notification, which users should receive it, and what the message says. Milliseconds if it is a simple rule, seconds if you queue it behind other work.
- Push gateway. Your backend hands the payload to Apple Push Notification service or Firebase Cloud Messaging, which alone can reach the handset. Typically under a second to accept.
- Gateway to handset. The genuinely unpredictable segment. Usually one to three seconds, occasionally minutes, and sometimes never — with no error returned to you.
A well-built chain delivers in five to fifteen seconds end to end for a mains-powered device. A battery product that sleeps between checks delivers in whatever its wake interval is, which is a firmware architecture decision long before it is an app one, as laid out in low-power firmware and sleep modes.
Push Delivery Is Best-Effort
This is the single most important thing to internalize: neither Apple nor Google guarantees delivery, and neither tells you when a message was dropped. Both operating systems actively throttle to protect battery life.
On iOS, low-priority pushes are held and coalesced at the system's convenience, background pushes are budgeted and can be limited to a few per hour, and only alert-priority messages are attempted immediately. If your app has been force-quit by the user, background pushes stop entirely. On Android, Doze mode batches deliveries into maintenance windows that can be fifteen minutes apart or longer, App Standby buckets further restrict apps the user rarely opens, and several manufacturers layer aggressive proprietary battery managers on top that kill background work the platform would have permitted.
The engineering conclusion is that push is a nudge, not a transport. Never send state in a notification and assume the app received it. Send a lightweight signal, and have the app fetch authoritative state from your backend when it opens. That same discipline keeps the product coherent when the phone was offline, which is the wider problem addressed in offline mode in a companion app.
When the Alert Genuinely Cannot Be Missed
Smoke, water, medical, and security products face a real problem: the phone is in Do Not Disturb and the notification is silent.
Apple provides the Critical Alert entitlement, which plays sound and bypasses both Do Not Disturb and the ringer switch. It is granted only by written application describing the safety justification, it is reviewed by hand, and it is refused for convenience features. Time-Sensitive notifications are the lighter-weight alternative and break through Focus modes without special approval. Android's equivalent path is a high-importance notification channel combined with a full-screen intent, which the store now also scrutinizes and restricts to genuine calls and alarms.
Two engineering realities follow. First, apply early — approval takes weeks and shapes your submission timeline. Second, a safety product cannot rely on push as its only alarm. A local siren in the device, an SMS or voice fallback through a provider, and a monitoring service integration are what make the claim defensible, which is standard practice in home safety product development. If the alert carries clinical meaning, the notification logic itself may fall inside the regulated software boundary described in software as a medical device.
Alert Fatigue Kills More Products Than Latency
Users disable notifications app by app, and once they do, you are gone permanently — no recovery path, no re-prompt, and no visibility into it beyond a drop in your delivery numbers. Consumer hardware apps routinely see a third or more of installs with notifications turned off within the first month, almost always because the product talked too much.
- Send state changes, not states. "Water detected" earns a notification. "Still no water" does not.
- Debounce aggressively. A sensor crossing a threshold repeatedly should produce one alert with a cooldown, not eleven.
- Separate channels by urgency — safety, action needed, informational, marketing — so a user can silence the last one without silencing the first.
- Batch the routine. A daily or weekly digest replaces dozens of individual pings.
- Ask permission in context. Requesting notification access at first launch converts poorly; requesting it the first time an alert would have fired converts far better.
- Measure it. Opt-out rate by channel is one of the highest-signal numbers in product app analytics.
Cost and Scale
The push gateways themselves are free at any volume you will plausibly reach. The cost sits in the pipeline behind them: persistent device connections, the rules engine that evaluates every event, and the fan-out when one device event must reach five household members. A fleet of fifty thousand devices generating a few events per day is a modest bill; the same fleet with a chatty firmware sending telemetry every ten seconds is a different conversation entirely, as broken down in IoT cloud infrastructure costs.
Building the Notification Layer
Projects House designs the firmware, backend, and app pieces of connected-product alerting together, including entitlement applications and fallback paths for safety-critical alarms. Tell us what your device needs to announce and how urgent it is through our contact form.