Notification as a service: what actually matters
Your deploy script finishes at 2am. Your payment webhook fires. Your scraper hits a rate limit. You want to know.
That scenario — a developer wanting to know something happened — is not what most “notification as a service” tools are built for. Understanding the split saves you from wiring up the wrong infrastructure.
Two different problems wearing the same name
Search “notification as a service” and you get two distinct categories of product:
User-facing notification platforms — Novu, Knock, Courier, OneSignal, Braze. These are built to help you send notifications to your users: transactional email when someone resets their password, push notification when a friend likes their post, SMS when a package ships. The value is in templating, multi-channel orchestration, subscriber management, and deliverability at scale. If you’re building an app and need to notify its users, this is the category you want.
Developer self-notification tools — Pushover, ntfy, trigger.fyi. These flip the direction. You’re the recipient. Your code fires a one-liner and your phone buzzes. No subscriber list, no template editor. The use case is monitoring, alerting, and staying aware of your own systems.
Both are legitimately called “notification as a service.” They are not interchangeable.
Evaluating user-facing NaaS
If you’re sending to users, the criteria are different from what this article focuses on. Short version: Novu and Knock are developer-friendly and API-first; Braze and OneSignal are better fits when your marketing team needs to own campaigns; Courier is strong if you need multi-channel with a visual workflow builder. Pricing models vary wildly — count events carefully before committing.
This article focuses on the other category: notifying yourself.
Evaluating developer self-notification tools
Four things matter.
Latency — is the send on your hot path?
Any notification library that blocks your request path is a liability. If fyi("payment received") adds 200ms to a checkout endpoint, you won’t use it in production.
Pushover’s API is simple but synchronous by default — if you’re calling it from application code you need to handle the async yourself. ntfy is self-hostable and fast, but again: the HTTP call is yours to manage. trigger.fyi is fire-and-forget at the library level — it never throws, caps at 3 seconds, and uses keepalive. On serverless functions (Vercel, Cloudflare Workers), un-awaited promises can be dropped before the runtime flushes — the recommendation is await fyi(...) or pass it to your platform’s waitUntil. The await is one edge roundtrip and can’t throw, so it’s safe on the hot path.
API ergonomics — can you curl it?
The simplest test of a notification API: can you use it without installing anything?
curl -X POST \
-H "content-type: application/json" \
-d '{"title": "Payment received", "body": "€29 · Pro plan", "meta": {"plan": "pro"}}' \
https://trigger.fyi/fyi_your_keyThat works. No SDK required. The key in the URL is the only auth. ntfy has a similar model — curl -d "server restarted" ntfy.sh/your-topic — and it’s excellent if you want self-hosting control. Pushover requires an application token and a user token, which means two values to manage.
Delivery reliability — platform-specific behavior
Push notifications are not uniform across platforms. iOS in particular.
iOS web push (added in 16.4, requires Add to Home Screen) cannot break the user’s Focus or silent mode. A critical or high-urgency flag will be delivered, but it won’t bypass silent mode the way native app notifications can. trigger.fyi’s fyi.critical() sends with Urgency: high and requireInteraction where supported, but documents clearly that on iOS it degrades to a normal push. That’s the honest behavior — any tool claiming otherwise is wrong about how iOS web push works.
Android is more permissive. High-urgency web push wakes the screen. FCM-backed tools (OneSignal, etc.) have more control through native channels.
ntfy handles this variation well if you’re self-hosting and controlling the client. Pushover has native iOS/Android apps and can break silent mode on iOS — if that’s a hard requirement and you want developer self-notification, Pushover is the honest answer.
Setup friction
ntfy: zero friction for sending, some friction if you want history and a real feed. Pushover: $5 one-time app purchase, two tokens to configure. trigger.fyi: npx trigger.fyi mints a key and opens a TUI feed — the key is ready to curl before you’ve read the output.
What the category actually splits on
If you’re sending to your users → Novu, Knock, Courier, OneSignal depending on whether you want developer APIs or marketer UIs.
If you’re notifying yourself from CI, scripts, or application code → ntfy if you want self-hosting and simplicity, Pushover if you need native iOS sound bypass, trigger.fyi if you want a structured feed with levels (fyi.log() for non-urgent, fyi.critical() for urgent) and ergonomics tuned for production code.
The category name is the same. The infrastructure, the mental model, and the right choice are not.