Push notification bugs are some of the hardest in mobile development to catch before production, because the failure mode is silence. A notification that never arrives doesn't throw an error anywhere visible to the sender. These six tools cover the gap between "the API call returned success" and "the notification actually reached the device," which is where most real-world push bugs actually live.
1. Firebase Cloud Messaging
Firebase is the underlying delivery infrastructure for the large majority of Android push notifications and a common choice for cross-platform delivery to iOS as well. Its console includes a message composer for sending test notifications directly to a specific device token without touching your backend code, which is the fastest way to confirm whether a delivery problem is on the client side or the server side. The delivery reports also break out send, deliver, and open events separately, which is useful for isolating exactly where a notification is getting lost.
Use the console's test-send feature first whenever a notification "isn't showing up." If a manually composed test message from the console doesn't arrive either, the problem is device or OS-level, not your integration code.
2. OneSignal
OneSignal is a free-tier push notification service with a dashboard built specifically around debugging delivery issues across platforms. Its delivery log shows per-device send status, including specific failure reasons like an expired token or a disabled notification permission, which is more granular error detail than most raw platform APIs surface directly.
It's a reasonable choice to prototype notification logic against before committing to a custom backend integration, since the free tier covers a meaningful volume of test sends during development.
3. Postman
Postman isn't push-specific, but it's the fastest way to manually construct and fire a raw push API request against Apple's or Google's servers to isolate whether a delivery problem is in your request payload or somewhere further downstream. Save a collection of known-good request templates for both platforms so a teammate debugging a delivery issue at 11pm doesn't have to reconstruct the correct headers and auth from scratch.
This matters more than it sounds like it should. A surprising share of "notifications aren't sending" bugs turn out to be a malformed payload or an expired signing certificate that a manual Postman request surfaces immediately, versus hours spent stepping through application code that was never the problem.
4. Pusher
Pusher offers a free development tier for real-time and push messaging with a debug console that shows live event traffic as it happens, which is useful for confirming that events are actually being triggered server-side before you go looking for a client-side receiving bug. Watching the live event stream while manually triggering an action in your app is one of the fastest ways to confirm the disconnect is happening after the trigger fires, not before.
5. Pushover
Pushover is a lightweight, low-cost notification delivery service popular for internal tooling and monitoring alerts, and it doubles as a useful sanity check tool during push development: send a test notification through Pushover's simple API to confirm your development device can receive push notifications at all, independent of your main app's integration. If Pushover notifications arrive fine but your app's don't, you've ruled out device settings and network issues and can focus entirely on your own integration code.
6. ntfy
ntfy is a simple, open-source publish-subscribe notification service you can self-host or use through its free public instance, and it's a genuinely useful sanity-check tool during development because sending a test push takes a single curl command with no SDK or app registration required. Firing off curl -d "test message" ntfy.sh/your-topic from a terminal and confirming it lands on a subscribed device in under a second is one of the fastest ways to confirm your development network and device configuration aren't the source of a delivery problem you were about to spend an hour debugging elsewhere.
Because it's minimal by design, it's not a replacement for a real production push pipeline. It's a fast, dependency-free way to isolate whether a "notifications aren't working" symptom is environmental or specific to your actual implementation.
Keeping a Shared Debugging Runbook
Individually, these tools solve isolated problems well. The bigger win comes from writing down, as a team, which tool to reach for at which symptom, so that debugging a delivery issue doesn't depend on whoever happens to remember the right approach that week. A short internal runbook covering the most common symptoms, "notification never arrives on any device," "notification arrives late," "notification arrives but doesn't open the right screen," each mapped to the specific tool and specific first check to run, turns a debugging session that might otherwise take an afternoon into one that takes twenty minutes.
Keep the runbook close to the code, not buried in a wiki nobody opens during an actual incident. A comment block near your notification sending code, or a short markdown file in the same repository, gets read far more reliably than documentation that lives somewhere separate from the code someone's actively debugging.
Free Tier Limits Worth Knowing Before You Rely on Them
Every tool on this list has a free tier, and every free tier has a ceiling worth knowing about before you build a habit around it. Firebase's console test-send and delivery reporting are free at any reasonable development volume. OneSignal's and Pusher's free tiers cover generous development and small-scale production use but do have monthly volume caps that matter if you're using them for more than isolated testing. Pushover charges a small one-time fee per platform rather than being purely free, which is worth knowing going in even though the cost is minor. ntfy's public instance is free and unauthenticated by default, which is great for quick tests but not something you'd want to route anything sensitive through without self-hosting your own instance instead.
Picking the Right Tool for Where the Bug Actually Is
Each of these tools is useful for a different layer of the delivery chain, and picking the wrong one for a given bug wastes time. If you suspect the problem is in your backend's request to the platform, Postman is the fastest way to isolate that, because it removes your application code from the equation entirely and tests the raw API call. If you suspect the problem is downstream of a successful API call, Firebase's or OneSignal's delivery logs will show you whether the platform actually attempted delivery and what happened when it did. If you're not sure the device itself can receive push notifications at all, independent of your app, ntfy or Pushover gives you a clean baseline test that rules the device and network in or out as suspects.
Real push bugs are rarely mysterious once you isolate the right layer. They're mysterious when every layer is tested together as one opaque black box, because a failure anywhere in the chain produces the exact same symptom from the outside: nothing arrived.
Building a Debugging Habit, Not Just a Tool List
The common thread across all six tools is the same debugging principle: isolate each layer, from API call, to delivery infrastructure, to device receipt, to app-level handling, and test each one independently rather than assuming a failure at any single layer. A notification that "just doesn't show up" usually has a specific point of failure somewhere in that chain, and the fastest path to a fix is testing each link separately instead of guessing at the whole pipeline at once.
Once delivery itself is reliable, the harder and more consequential problems, like whether users keep the channel enabled at all, become the real bottleneck. https://137foundry.com has a longer guide on that side of the problem, covering permission timing, frequency caps, and the platform-specific behavior that determines whether a technically well-delivered notification actually helps or costs you the channel long term.
Top comments (0)