Get a Server Down Phone Notification the Moment Your Site Goes Offline

Your site went down at 2 a.m. on a Tuesday. You found out at 8:40 — from a "hey, is your site broken?" message, not from your own tooling. Those six hours of dark are exactly what this post is about getting rid of.

Uptime services exist, sure. But half of them want you to create an account, add a card, and learn their dashboard before they'll send a single alert. All you actually want is one thing: when the server stops answering, your phone buzzes. That's it.

You can build that in about five minutes with a cron job, curl, and one HTTP POST. No agent to install on the box, no daemon, no third-party dashboard to babysit.

The idea: poll, then ping

The whole thing is two steps. Hit your server's URL on a schedule. If it doesn't answer, send yourself a push notification. Here's the smallest version that works — drop it straight in your crontab:

curl -fs --max-time 10 https://yoursite.com/health > /dev/null || \
curl -s -X POST https://thenotification.app/api/sendNotification \
  -H "app_key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"🔴 Server down","body":"yoursite.com stopped responding"}'

The -f flag makes curl treat any 4xx/5xx as a failure, and --max-time 10 means a hung server counts as down too. If that first request fails, the || fires the second one and your phone lights up. Grab your app_key from the dashboard — the full request shape is in the curl docs.

The problem with the simple version

Run that every minute and the day your server actually goes down, you'll get a notification every minute until you fix it. At 3 a.m. that's not an alert, it's a punishment.

What you want is a ping when the state changes — once when it goes down, once when it comes back. That needs a little memory between runs. A file in /tmp does the job:

#!/usr/bin/env bash
URL="https://yoursite.com/health"
APP_KEY="YOUR_API_KEY"
STATE_FILE="/tmp/uptime-yoursite.state"

notify() {
  curl -s -X POST https://thenotification.app/api/sendNotification \
    -H "app_key: $APP_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"title\":\"$1\",\"body\":\"$2\",\"link\":\"$URL\"}" > /dev/null
}

if curl -fs --max-time 10 "$URL" > /dev/null; then
  current="up"
else
  current="down"
fi

last=$(cat "$STATE_FILE" 2>/dev/null || echo "up")

if [ "$current" != "$last" ]; then
  echo "$current" > "$STATE_FILE"
  if [ "$current" = "down" ]; then
    notify "🔴 Server down" "$URL stopped responding"
  else
    notify "🟢 Back up" "$URL is responding again"
  fi
fi

Save it as uptime-check.sh, make it executable, and run it every minute from cron:

* * * * * /path/to/uptime-check.sh

Now you get one "down" ping when it breaks and one "back up" ping when it recovers. Silence the rest of the time. The link field puts the URL one tap away, so you can check from your phone before you even reach a laptop.

Prefer Python? Same idea, more control

If you want to treat a 500 differently from a connection refused — you care about your app erroring versus the whole box being unreachable — Python's requests makes that readable:

import requests

URL = "https://yoursite.com/health"
APP_KEY = "YOUR_API_KEY"

def notify(title, body):
    requests.post(
        "https://thenotification.app/api/sendNotification",
        headers={"app_key": APP_KEY},
        json={"title": title, "body": body, "link": URL},
        timeout=10,
    )

try:
    r = requests.get(URL, timeout=10)
    if r.status_code >= 500:
        notify("🔴 Server error", f"{URL} returned {r.status_code}")
except requests.RequestException as e:
    notify("🔴 Server down", f"{URL} is unreachable: {e}")

Add the same state-file trick if you run it on a schedule, and you've got a monitor that knows the difference between "the app threw a 502" and "nothing's picking up the phone at all."

Real talk: don't let a flapping server eat your quota

The free tier is 100 notifications total — not per month, total. That's plenty for the state-change approach, where a healthy server sends zero notifications for weeks on end. But skip the state file and alert on every failed check, and a server that flaps up and down for an hour can burn through dozens in one night. If you're watching more than a couple of things, the Pro plan at $2.99/month gives you 1,000 notifications a month — still cheaper than most uptime services' starter tier. Either way: alert on transitions, not on every poll.

Where to go from here

This poll-and-ping pattern covers more than a single web server. Point it at a database health endpoint, a queue-depth metric, or an SSL cert expiry check — anything that returns a URL you can curl. If you're already wrapping scheduled jobs, the cron job failure alerts guide pairs nicely with this one.

It's free to try, no card required — grab a key, wire up the one-liner, and kill your own dev server to watch your phone light up. Beats hearing about it from a customer.