UnifiedPush and Public ntfy.sh: Why Push Notifications Fail on Android Without Google Services

Developers of a messenger operating in a region where Google services are unavailable faced the familiar problem of replacing FCM. The standard open-source answer is UnifiedPush, which splits delivery among the app, the application server, and a distributor that maintains a connection to a push server. The team implemented this approach in June using the popular ntfy distributor paired with the public ntfy.sh instance.

One and a half months later, user complaints about missing notifications prompted an examination of production logs. Over a 36-hour window the server recorded 100 successful deliveries against 507 responses with code 507 (Insufficient Storage), 351 with code 429 (Too Many Requests), and 69 with code 400 (Bad Request). Failures had been present since the feature launch; they simply went unnoticed on always-connected test devices.

The 507 errors stem from a deliberate design choice in ntfy: when visitor-subscriber rate limiting is enabled, a UnifiedPush topic must have an active subscriber before any message can be published. The official ntfy client from Google Play uses Firebase for instant delivery and only maintains a persistent WebSocket when the F-Droid build is used. In regions without Google services the client never registers a subscriber, so every server POST receives an immediate 507 and the message is discarded rather than queued.

Code 429 responses arise because rate-limit buckets are attached to the subscriber’s IP address, not the sender. Mobile carriers place hundreds of users behind a single NAT address; a single group message can exhaust the shared 60-request bucket and cause subsequent deliveries to fail for unrelated users sharing the same IP. Many endpoints alternated between 429 and 507 within a single day, producing the intermittent behavior reported by users.

Endpoints pointing at updates.push.services.mozilla.com returned 400 because the server implements the WebPush specification (RFC 8030), which requires a TTL header. The original implementation omitted the header, assuming ntfy behavior would apply to every endpoint. The team now sends a minimal WebPush-compliant request containing Content-Type, TTL, and Urgency headers for all destinations.

Purchasing a paid ntfy.sh plan does not resolve the problem. Both the subscriber-existence check and the rate-limit logic operate on the recipient side; elevating the sender’s quota has no effect. The developers therefore deployed a self-hosted ntfy instance with visitor-subscriber-rate-limiting disabled, a generous burst limit of 200 requests, and an exempt host list that includes the backend address.

Even a private push server leaves users with the burden of installing and configuring a separate distributor application. To remove this friction the team implemented an embedded distributor directly inside the messenger. The component consists of a BroadcastReceiver that answers REGISTER requests and a foreground service maintaining a WebSocket to the private server. The WebSocket reconnect logic includes a “since” parameter so cached messages are delivered after network interruptions.

Two device-only bugs surfaced during live testing. Re-registration generates a fresh topic, yet the service continued listening on the old topic until an explicit comparison was added. Closing an obsolete socket triggered an onClosed handler that scheduled a duplicate reconnect, resulting in duplicate notifications; a generation counter now prevents the second connection from processing events.

Finally, the push WebSocket must traverse the same anti-censorship tunnel used by the rest of the application. Because OkHttp caches the route at client creation time, the service recreates the HTTP client whenever the tunnel state changes, ensuring notifications remain available even when the primary domain is blocked.