How do I get notified when my website goes down?

The most reliable way to get notified when your website goes down is an uptime monitor: a service that requests your site on a fixed interval — every minute to every few minutes — and alerts you the moment a check fails. The alert has to arrive somewhere that actually interrupts you, such as a push notification on your phone, not an inbox you read twice a day. You can have this running in a few minutes with a hosted monitor, or build a minimal version yourself with cron and curl.

This guide covers both approaches, and then the part most setups miss: the two failures an HTTP check can never see — scheduled jobs that silently stop running, and traffic that quietly collapses while your site keeps returning 200.

What does "down" actually mean?

"Down" is not one condition. Websites fail in several distinct ways, and each one looks different to a monitor:

• The server is unreachable. The machine is off, the network route is broken, or the web server process died. Requests time out or are refused.
• The application is erroring. The server answers, but with a 500-class status — a crashed backend, a failed database connection, a broken deploy.
• The TLS certificate expired. Browsers show a full-page security warning and most visitors leave. The site is technically serving; nobody can use it.
• DNS is broken. The domain no longer resolves — an expired registration, a bad zone edit, or a nameserver change gone wrong.
• It is too slow to use. Responses arrive, eventually. For a visitor on a checkout page, a thirty-second response and an outage are the same thing.

A basic HTTP check catches all five, because each one changes what a request observes: a timeout, an error status, a certificate failure, a resolution failure, or a response time past your patience. That is why the humble "request the homepage every minute" check has survived every generation of monitoring tooling — it measures what a real visitor experiences.

Option 1: use a hosted uptime monitor

A hosted uptime monitor does the checking for you: you give it a URL and an interval, it requests that URL on schedule, and when requests fail it opens an incident and notifies you. Two settings matter more than the rest:

• The check interval sets your worst-case detection delay. A 1-minute interval means you hear about an outage within a minute or two; a 5-minute interval can add several minutes of silence on top.
• The failure threshold controls false alarms. Networks hiccup, so a single failed request should not page you at 3 a.m. — requiring consecutive failures filters out transient blips at the cost of a little detection time.

Pingwire's uptime monitoring works exactly this way: you add a URL and an interval, and when checks fail an incident opens and the alert reaches your devices as a push notification. Incidents can be acknowledged and resolved, so on a small team everyone can see who is already looking; escalation policies can notify a shared channel when nobody reacts in time; and a public status page can tell your users what you already know. On the free plan you get 3 monitors at a 5-minute interval with 7 days of history; Pro raises that to 25 monitors, 1-minute intervals, and 90 days of history — and while Pingwire's billing is in free mode, every account gets the Pro limits at no cost.

One honest note: an external monitor tells you your site is unreachable from the monitor's network. That is almost always the signal you want — it approximates the visitor's view rather than the server's own opinion of itself — but it is worth knowing precisely what the alert means when it fires.

Option 2: build your own with cron and curl

The DIY version is one short script: request the site, and if the response is an error or a timeout, send yourself a push notification. Using the same API from our earlier post on sending push notifications from a bash script:

#!/usr/bin/env bash
# check-site.sh — run from cron on a DIFFERENT machine than the site
URL="https://example.com/"
STATUS=$(curl -sS -o /dev/null -w "%{http_code}" --max-time 10 "$URL" || echo 000)

if [ "$STATUS" -ge 500 ] || [ "$STATUS" = "000" ]; then
  curl -sS -X POST https://pingwire.dev/api/v1/messages.php \
    -H "Authorization: Bearer $PINGWIRE_KEY" \
    -H "Content-Type: application/json" \
    -d "{\"channel\":\"ops\",\"title\":\"Site DOWN\",\"text\":\"$URL returned $STATUS\",\"priority\":\"urgent\"}"
fi

Add a crontab line — * * * * * /usr/local/bin/check-site.sh — and you have a working one-minute monitor for one site.

Where the DIY version falls short

This script is genuinely useful, and it is also worth being honest about what it lacks:

• It watches from inside your own infrastructure. If the checker runs on the same server as the site — or the same provider, or behind the same router — the failure that takes the site down takes the watcher down with it. Silence from the monitor looks identical to "everything is fine."
• It has no memory. During a forty-minute outage, the script fires every minute. Adding "only alert on state change" means storing state, and now you are maintaining a small monitoring product.
• It never tells you the site recovered, and it keeps no history, so "how long were we down last night?" has no answer.
• One transient network blip is one alert. Consecutive-failure thresholds are yet more state to build and test.

(Pingwire's machine-sender dedupe softens the repeat-alert problem — identical text from the same sender within 60 seconds collapses into one message — but a long outage still means a stream of messages rather than one incident with a start, an acknowledgement, and an end.)

The outage an HTTP check cannot see: jobs that silently stop running

Your website returning 200 does not mean your backups ran last night. Cron jobs, queue workers, and certificate renewals fail in a uniquely nasty way: they stop happening, and nothing happening is exactly what silence looks like. A monitor requesting your homepage will never notice.

The fix is to invert the direction of the check with a heartbeat monitor (also called a dead man's switch): instead of the monitor reaching out to your site, your job checks in every time it succeeds, and the alert fires when the check-ins stop arriving. It costs one line at the end of the job:

0 3 * * * /usr/local/bin/nightly-backup.sh && curl -fsS --retry 3 https://pingwire.dev/hb/YOUR-TOKEN > /dev/null

The && matters: the heartbeat is only sent when the backup exits successfully, so a failing job and a missing job both surface the same way — the pings stop, and you get notified. Pair heartbeats with your uptime monitor and you cover both directions: the monitor catches the site that stopped answering, the heartbeat catches the job that stopped running.

The other silent failure: traffic that collapses while the site returns 200

There is a class of outage where every check passes and the site is still effectively down: DNS breaks for part of the internet but not for your monitor, a search engine drops you, a broken deploy strands your signup form, or a misconfigured CDN serves errors to real browsers but not to curl. The symptom in every case is the same — your traffic falls off a cliff while your uptime dashboard stays green.

Traffic alerts watch request volume instead of request success, and notify you when traffic drops abnormally against its usual pattern. It is a coarser signal than an HTTP check, but it is the one that catches "up, but nobody can reach us."

How should the alert actually reach you?

Detection is only half the problem; the alert has to interrupt you. Pingwire delivers alerts as web push notifications: install the web app to your phone's home screen, enable notifications, and monitor alerts land on your lock screen like any app notification. This works on Android and — since iOS 16.4 — on iPhone, where the site must be installed to the home screen first. The underlying standard is the Push API; no native app or app store is involved. Pingwire does not send SMS or place phone calls, so if your escalation policy ultimately requires a ringing phone to wake someone, pair it with a tool that does that.

For a team, point the monitor's alerts at a shared channel rather than one person, and let acknowledgement do its job: when someone acks the incident, everyone else can stand down.

A setup you can finish today

1. Create an uptime monitor for your homepage, and a second one for an endpoint that exercises your application — a health route that touches the database — so you catch app failures, not just server failures.
2. Add a heartbeat to every scheduled job whose silent failure would hurt: backups, certificate renewal, billing crons.
3. Add a traffic alert if your site's value depends on people actually arriving.
4. Install the web app on your phone and send a test notification. An alerting pipeline you have never seen fire is not yet a pipeline.
5. Write down, even in two sentences, what you will do when the alert arrives: where the logs are, how to restart the service. Future-you at 3 a.m. will be grateful.

Downtime is not a moral failing — every site goes down eventually. The difference between a bad night and a bad week is whether you found out from a monitor two minutes in, or from a customer the next morning.