Skip to content

Guide

How to get alerted when your website goes down, without false alarms

An alert you learn to ignore is worse than none. Most false alarms come from one check, from one place, failing once. Here's what to watch, and how to make an alert mean your site is really down.

Why one check cries wolf

A single failed check usually isn't an outage:

  • A blip at the checker. The machine doing the check lost its network for a moment, or its route to your server did.
  • A slow DNS answer. Looking up the name took too long, so the check gave up before it reached your site.
  • A restart. A deploy restarted the app, and for a few seconds nothing answered.

Your visitors didn't notice any of these. If each one wakes you, you'll start muting the alerts, and then miss the real one.

What to watch

  • The status code. The page answers with 200, not an error or a sign-in page.
  • A word that must be on the page. A server can answer 200 with an error message or an empty page. A word that's there only when the page works catches that.
  • The certificate. A certificate that runs out makes browsers refuse the site. Get a warning weeks before.
  • The domain's renewal. A lapsed domain takes everything down at once, email included.

How to cut false alarms

  • Confirm from a second place. When a check fails, check again at once from somewhere else, on another network, and alert only if that fails too. This takes out the checker's own blips.
  • Wait out short blips, if you like. Alert only if it's still down after a few minutes. You hear about real outages a little later, and about restarts never.
  • Two good checks before "up". A site that flaps, up and down and up, shouldn't alert each time. Call it recovered after two good checks in a row.

To do it yourself, run the same check from two servers in different regions, and alert only when both fail:

# On two servers in different regions, every minute:
curl -fsS -o /dev/null --max-time 10 https://example.com/ || echo "down from $(hostname)"
Then both servers need watching, and a way to agree before they alert.

With BadgerBell

  • Each check comes from one place, taking turns: San Francisco, Frankfurt and Singapore. When one fails, BadgerBell asks again within seconds from the two other places, and you hear about it only if 2 of 3 agree.
  • A probe that's having problems is set aside, and its results don't count.
  • Back to "working" only after 2 good checks in a row.
  • Alert only if it's still down after 1 to 15 minutes, if you like. It starts at 0.
  • A website monitor can look for a word on the page, and every website monitor also watches its certificate and domain, which don't count toward your plan.
  • Alerts by email, Slack and webhooks on every plan, Free included, and by text on paid plans.
  • Free has 10 monitors, checked every 5 minutes. Indie has 50, checked every minute, for $9 a month.

Set it up with your assistant

Connect BadgerBell, paste one prompt, and your assistant proposes your monitors.

1. Connect BadgerBell
claude mcp add --transport http badgerbell https://app.badgerbell.com/mcp
Your assistant asks you to sign in to BadgerBell. You see every connected agent, and can revoke it, in the app.
2. Paste this prompt
Look at this project and list what should be watched: the website, the API's health address, scheduled jobs and backups, and any MCP server. For each one, propose a BadgerBell monitor: its type, its address and what counts as working. For each scheduled job, show me the line to add that pings its heartbeat. Show me the whole list first, and add the monitors in BadgerBell only after I say yes.

Anything public or destructive waits for you in BadgerBell.