Tool
ntfy
A simple pub-sub push notification service — HTTP PUT or POST to a topic, phone and desktop apps listen. Use the public ntfy.sh server or run your own.
What it is
ntfy (pronounced “notify”) lets scripts, monitors, and homelab jobs send push notifications with plain HTTP. You pick a topic name, subscribe in the Android/iOS/desktop app (or web), then curl -d "Backup done" ntfy.sh/your-topic (or your self-hosted host). Topics are created on first use. Official docs cover publishing, attachments, priorities, actions, and auth. Source lives at github.com/binwiederhier/ntfy.
What it replaces
It replaces “page me via Twilio SMS / email alert spam / a bespoke webhook glue” for uptime and script alerts when you want one lightweight channel to phone and desktop — especially beside Uptime Kuma, cron jobs, and backup scripts.
It does not replace a full incident platform (PagerDuty-shaped routing, on-call schedules, acknowledgements as a product). It is not a chat app or a general messaging bus. Delivery still depends on platform push (FCM/APNs) for mobile apps.
License
The ntfy server and related open-source components are released under the Apache License 2.0, verified from the project’s primary LICENSE on GitHub. Mobile apps and the hosted ntfy.sh service have their own terms of use; rate limits and fair-use rules apply on the public server. Self-hosting means you own ops and exposure.
Where it falls over
- On public ntfy.sh, topic names are effectively secrets — guessable topics mean strangers can publish (or listen). Prefer long random topic names; use auth when self-hosting.
- Self-hosting adds ACL/auth config, TLS, upgrades, and backup of config — not “zero ops.”
- Mobile delivery depends on FCM (Android) and APNs (iOS); if those pipes fail or the app is force-stopped, you may miss alerts.
- Public server rate limits and abuse controls apply — fine for personal scripts, not a free unlimited SaaS pager.
- Not a full incident-management suite: no built-in on-call roster, escalation policies, or ticketing.
- Attachments and large payloads have size/rate limits; treat it as alerts, not a file-transfer channel.
Who it's for
Homelab operators and small teams who want script-friendly push alerts without standing up SMS billing — especially next to Uptime Kuma, n8n, or backup cron. Not a substitute for designing what “wake me up” means, or for hardening a publicly exposed notification endpoint.
Related in this cluster
- Uptime Kuma — common pairing for monitor → notify
- n8n — workflow automation that can call ntfy
- Docker — usual self-host install path
- Tailscale — private reach to a self-hosted ntfy without hanging it naked
- Home Assistant — another common notify target / source in a local stack
- Self-hosting hub — more open replacements and plumbing
Verdict
Use ntfy when you want HTTP-simple push for scripts and uptime alerts. Start on ntfy.sh with unguessable topics for personal use, or self-host with auth when the alerts matter. Pair with Uptime Kuma; don’t confuse Apache-2.0 code with an unlimited public pager or a full incident platform.