Why Your Uptime Monitor Cries Wolf

The failure mode that kills most monitoring setups is alerting so often that people stop looking. Once a team has learned that the 3am alert is probably nothing, the system has quietly stopped working, and the dashboard will keep showing green checkmarks while it does.

Alert fatigue is a design problem. It has specific causes, and you can remove them one at a time.

One failed request proves nothing

The internet drops packets. TLS handshakes occasionally time out. A load balancer rotates a node mid-request. None of these mean your site is down, and all of them will produce exactly one failed check.

If your monitor opens an incident on the first failure, you have built a very sensitive detector of ordinary internet weather.

The fix is confirmation. Barkme retries a failed request after two seconds, and then requires two consecutive failed checks before it opens anything. That is four failed requests before your phone makes a sound. A single blip cannot get through, and a genuine outage still gets caught within a minute on a fast interval.

The important detail is what happens to the clock. The incident is backdated to the first failed check, so waiting for confirmation does not quietly inflate your uptime percentage. You get a calmer alert and an honest number.

A redirect can hide a dead site

This one surprises people. A 301 or 302 is a perfectly healthy HTTP response, and a monitor that treats any non-error status as "up" will happily report green while your entire site redirects to a parked domain or a broken CDN.

Barkme counts only a 2xx as up. Everything else is down: 3xx, 4xx, 5xx, a timeout, or a DNS or TLS failure.

That strictness has a practical consequence you should know about before it bites you. If you monitor example.com and the site redirects to www.example.com, you will get an alert on the redirect. Monitor the URL your visitors actually land on, the one at the end of the redirect chain. It takes ten seconds to fix and it removes a whole category of confusing alerts.

The timeout is too tight

A timeout is a claim about how slow is too slow. Set it near your normal response time and every ordinary spike in load becomes an outage.

Response times are never a flat line. A page that usually answers in 300ms will occasionally take two seconds because a cache expired, a neighbouring tenant got busy, or a garbage collector ran. That is not downtime.

Set the timeout at roughly three times your typical response time. If a page normally takes one second, ten seconds is a reasonable ceiling. If you find yourself pushing the timeout past thirty seconds to stop the alerts, the alerts are correct and the page is the problem.

You are monitoring the most expensive page on the site

A common setup is to point the monitor at the homepage, because that is the URL everybody knows. On many sites the homepage is also the heaviest thing there: personalised blocks, a product feed, three database queries, a call to a pricing API.

Now your uptime signal depends on every one of those staying healthy, and a slow third-party API becomes "the site is down."

Point monitors at a small, dedicated health route that returns quickly and touches only what you actually want to be alerted about. Monitor the expensive page too if you like, on a slower interval and with a longer timeout, and understand that it is measuring something different.

Every alert goes to everyone

If four people get paged for the same incident, three of them learn that alerts are somebody else's problem. This is the fastest way to train a team to ignore a channel.

A few things help:

• One open incident per monitor. A four-hour outage should produce one alert and one recovery notice. Barkme opens at most one incident per monitor at a time, so a long outage cannot turn into a stream of eighty messages.
• Separate the channel from the audience. Personal channels like email and Telegram reach one person. Shared channels like Slack, Linear and Trello reach the team. Route production to the place someone is accountable for, and staging somewhere nobody is paged.
• Close the loop automatically. Barkme's Linear and Trello channels open an issue or card when an incident starts and close it when the site recovers, so nobody triages an alert for a site that came back twenty minutes ago.

Muting beats deleting

When a channel is genuinely too noisy during a migration or a planned maintenance window, mute it. Deleting a channel means someone has to remember to recreate it, and that is exactly the sort of thing that gets forgotten until the next real outage.

Closing should be faster than opening

There is an asymmetry worth building deliberately. Opening an incident should be cautious, because a false alarm costs trust. Closing one should be immediate, because a stale open incident costs attention.

Barkme resolves an incident on the first successful check, with no confirmation window, and sends a recovery notice with the total downtime.

If your tool requires several consecutive successes before it will admit the site is back, you will spend the recovery period explaining to people that it is already fine.

A checklist for a quiet monitor

Work through this once and most of the noise disappears:

1. Monitor the final URL after redirects.
2. Point the monitor at a lightweight health route.
3. Set the timeout to about three times the normal response time.
4. Confirm failures before alerting. Never page on a single failed request.
5. Send staging and internal monitors somewhere that does not wake anyone.
6. Make sure recovery notices arrive, so nobody chases a resolved incident.
7. When a monitor flaps repeatedly, fix the host. Raising the threshold only hides it.

That last one matters most. A monitor that keeps opening and closing incidents is telling you something true about your infrastructure, and turning down its sensitivity is how you arrange to be surprised later.

For the mechanics of intervals and timeouts, see how often you should check your site is up. For the failures that produce no failed requests at all, see the expiry dates that take sites down. And if you want to know what a 502 at 3am actually means, the status code field guide goes through them one by one.