Public HTTPS down, disk at 95%, MySQL dead — three different scripts, three different curl ntfy.sh/… URLs, and a secret you will never rotate. Point them all at AlertHub and paste one ntfy topic. The phone sees a single feed; the dashboard stays searchable.
AlertHub is not a probe network. UptimeRobot (or cron) still checks the site. Bash still runs df and systemctl. ntfy is only the last mile.
Existing how-tos: uptime monitoring, disk usage, service watchdog. This post is how they share a topic without waking you for every 81% disk tick.
What rings vs what waits
| Signal | Source | Level | ntfy priority |
|---|---|---|---|
| Site / API down | UptimeRobot, Healthchecks, email ingest | Critical | 5 |
| MySQL / Nginx / SSH down | check_services.sh | Critical | 5 |
| Disk ≥ 90% | check_disk.sh | Critical | 5 |
| Disk ≥ 80% | check_disk.sh | Warning | 4 |
| Recovery / “up again” | Monitor up webhook | Info | — (dashboard only) |
Do not send success or recovery as warning. People ignore a topic that celebrates as loudly as it pages.
Setup (once)
- One AlertHub project (or
prodvsstagingif staging timeouts must never page). Copy the secret key. - Keep the existing POSTs to
https://api.thealerthub.com/sendAlert— do not replace them with raw ntfy curls. - Subscribe to an unguessable ntfy topic and paste
https://ntfy.sh/YOUR_TOPICin Connections → ntfy.
If a monitor can only email, use email ingest → ntfy on the same project.
Alert 1: Public uptime (UptimeRobot or any HTTP notify)
Point the monitor at AlertHub with ah_level=critical and ah_source=UptimeRobot. Query-style URLs from the uptime guide still work. ntfy gets priority 5. A second URL with ah_level=info is enough if you want a recovery row in the feed.
Alert 2: Disk threshold without crying wolf
The disk script already POSTs when usage exceeds a threshold. Use warning at 80% (ntfy 4) and bump the script to critical at 90%+ if you want the urgent banner. Cron every 15–60 minutes; do not POST on every run when usage is fine.
Alert 3: systemd services
check_services.sh should send critical when mysql, nginx, or ssh is inactive. Same ALERTHUB_KEY, ah_source set to the hostname so two VPS do not look identical on the lock screen.
Ideas to squeeze more value
ah_sourceis the filter.prod-web-01,UptimeRobot,disk-cron— one topic, readable history.- Staging never on ntfy. Separate project, or keep staging at
info. - Self-hosted Android ops. Same three scripts, Gotify instead of ntfy.
- GitHub deploy + uptime. Failed ship via Actions → ntfy; failed probe via this topic. Same phone, different titles.
FAQ
Does AlertHub ping my site?
No. The monitor or cron does. AlertHub stores and routes.
Can I keep Slack for the team?
Yes. ntfy for the person holding the pager, Slack for the channel — hybrid on-call.
Why not curl ntfy from each crontab?
Rotating the topic then means SSH to every host. AlertHub is one Connection.
Next steps
Point one monitor and one disk check at the same project, paste an ntfy topic, and force a warning.
Related: ntfy setup · Uptime to Slack/Telegram · GitHub Actions → ntfy