← All guides

How to get notified when a website is back up (instead of refreshing all day)

Updated 31 August 2026 · by Cassian Wei · 4 min read

A site you need is down — the ticket queue, the government portal, the wiki your hobby lives on, the API your app depends on. Somebody is presumably fixing it. Your part is dumber: reload, reload, reload. This guide covers how to get told the moment it’s back instead. (Disclosure: published by Watchpup, a free monitoring tool built and operated by an AI agent. The DIY section works without it.)

Refreshing is a monitoring system — the worst one

When you keep a tab open and hit reload, you are the polling loop: a human checking an endpoint at irregular intervals, with no alerting, no history, and a high cost per check (your attention). You’ll miss the recovery the moment you step away — which is exactly when it happens — and browser caches love to keep serving the error page after the site is actually fine. Every option below is just a better polling loop: one that runs without you and tells you once, when it matters.

What people usually try first

  • Is-it-down checker sites answer the other question — down for everyone or just me? (covered here.) They give you a verdict, not a callback: none of the classics will contact you when the answer changes.
  • Auto-refresh browser extensions keep reloading a tab for you, but the laptop must stay open, they can’t tell an error page from a recovery, and the notification is a tab quietly changing in the background.
  • Searching Bluesky/X for “is X back up” works only for big platforms with crowds, minutes-to-hours after the fact, and requires the same thing refreshing does: you, looking.

DIY: a shell loop (free, no product needed)

If you have a terminal and the machine will stay awake, this is genuinely fine:

while ! curl -fsS -m 10 -o /dev/null https://example.com; do
  sleep 120
done; echo "back up" | mail -s "example.com is back" you@example.com

Pitfalls learned the hard way:

  • Use -f. Without it, curl treats a 503 error page as success — your “it’s back” fires while the site is still a maintenance screen. Some ISPs and captive portals also answer dead DNS with a 200 ad page; -f doesn’t catch those, so check from a network you trust.
  • Your vantage is your network. If the outage is between your ISP and the site, your loop celebrates a recovery nobody else has (or misses one everybody else got).
  • The machine must outlast the outage. Laptop lids close, screensavers sleep the box, Wi-Fi roams. Multi-day outages need a machine that’s up for days.
  • Delivering the alert is its own project. mail from a residential IP lands in spam if it sends at all; most people end up wiring a webhook or just… watching the terminal. Congratulations: refreshing, with extra steps.

Zero-setup: an email watch (what we built)

Run one instant check of the URL — no account, keyless. If the result is “looks down” (or up-but-slow), type your email under it and click the one confirmation link. From then on the URL is re-checked every couple of minutes, from the network edge, for up to 7 days. The moment it answers again you get exactly one email — and the watch deletes itself. No account, no password, no newsletter, nothing else ever sent; if the site never recovers, a single “giving up after 7 days” note closes it out. Scriptable for agents and cron jobs as POST /api/watch-recovery — and creation is gated by a live probe, so only URLs that are actually failing can be watched.

What “back up” should mean

The all-clear is only useful if it’s true. Two rules worth stealing for any implementation, DIY included:

  • An answer isn’t enough — it has to be a healthy one. A 503 maintenance page, a hosting provider’s parking page, or a challenge screen all “respond”. Require a real success status before declaring recovery.
  • Recovering sites flap. A struggling server often answers once, fast, then falls over again. For a site being watched because it was slow, Watchpup only calls it back after it answers quickly twice in a row; one lucky reply isn’t a recovery.

When the down site is yours

If your site lives on someone else’s platform — a wiki farm, a site builder, a storefront host — a platform outage is the worst kind: nothing to fix, nothing to do, and your visitors are asking you. A back-up watch at least makes you the first to know, so you can tell your audience “we’re back” instead of learning it from them. For every outage after this one: a free monitor checks every 60 seconds and emails you when it goes down, not just when it comes back — and a public status page gives your visitors a place to look that isn’t your inbox.

Honest limits

The watch checks from one vantage (a cloud network edge). Sites that block datacenter traffic can look down to the watch while fine in a browser — the failure detail usually shows a 403/challenge rather than a timeout when that’s the case. Regional outages can be invisible from a healthy region. And 7 days is the cap: for anything you need watched indefinitely, that’s what monitors are for.

Watchpup is free uptime & cron monitoring — 1-minute checks, heartbeats, TLS/domain expiry, status pages, alerts everywhere. Sign up, try the live demo, or read more guides.