get free phone alerts from any script with ntfy

your backups are probably failing silently right now

here's an uncomfortable truth about homelabs and small servers: most people find out their backup job broke when they actually need the backup. the cron job died three weeks ago, nobody noticed, and now you're restoring from a backup that doesn't exist. the fix isn't complicated monitoring software. it's a free tool called ntfy that lets any script on any machine push a notification straight to your phone.

no accounts tied to your identity, no monthly fee, no SDK to install. just a url and a message. let's break down how it works and how to use it without creating a new hole in your setup.

what ntfy actually is

ntfy (pronounced "notify") is an open source pub/sub notification service. you pick a "topic" which is really just a string that acts like a channel name. you subscribe to that topic in the ntfy app on your phone. then anything, anywhere, that knows that topic name can send a message to it with a simple http request. the public server at ntfy.sh is free to use, or you can self-host it since the whole thing is open source.

think of a topic like a radio frequency. anyone who knows the frequency can broadcast on it, and anyone tuned in hears it. that detail matters a lot for security, and we'll get to it.

breaking down the command

curl -d 'message' ntfy.sh/your-topic

here's what each piece is doing:

curl is just making an http request, nothing fancy, available on basically every linux box and mac by default.

-d 'message' sends "message" as the body of a POST request. this is the actual text that shows up as your notification.

ntfy.sh/your-topic is the public ntfy server plus your topic name. whatever you put after the slash is the "channel" your phone is subscribed to.

that's the entire mechanism. no api keys, no auth headers, no setup on the server side beyond picking a topic name. you can literally test this right now by subscribing to a topic in the app and running the curl command from your laptop.

wiring it into something that actually matters

a notification that just says "message" is cute but not useful. the real value is hooking this into scripts that already run unattended, like backup jobs, cron tasks, or health checks. here's a pattern for a backup script:

if ! rsync -a /data /mnt/backup; then
  curl -H "Priority: urgent" -H "Title: backup failed" \
    -d "rsync job on $(hostname) failed at $(date)" \
    ntfy.sh/your-topic
fi

the Priority: urgent header makes the notification bypass your phone's do-not-disturb and show up with sound, which matters at 3am when a disk fills up. you can also set priority levels for less critical stuff so you're not trained to ignore every alert like a car alarm nobody checks anymore.

the defensive point here is simple: a system that tells you when it breaks is a system you can actually trust. silent failure is the default state of unmonitored infrastructure, and most home servers are unmonitored infrastructure.

the part everyone skips: topic security

since anyone who knows your topic name can both read and write to it on the public server, "your-topic" being something guessable like "backups" or "homelab" means a stranger could spam your phone with fake alerts, or worse, see real alerts about your systems if they guess the name. this is genuinely important for anyone putting this in production.

two real fixes:

1. use a long, random topic name. something like ntfy.sh/x7k2m9-backup-status-q4f1 instead of ntfy.sh/backups. treat it like a password, not a label.

2. self-host ntfy with authentication. the project supports access tokens and user accounts if you run your own instance in docker. this is the right call if you're sending anything sensitive, like alerts that include hostnames, ip addresses, or details about what failed.

the takeaway

free monitoring that fits in one line of bash is rare, and ntfy is one of the few tools that actually delivers on that. the point isn't to notify yourself about everything, it's to close the gap between "something broke" and "you know something broke." start with your backup jobs, pick a topic name you wouldn't want a stranger to guess, and if you're sending anything you'd be upset about a random person seeing, self-host it with auth instead of trusting the public server. your infrastructure should talk to you before it fails you.