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 is not an outage

Plenty of sites redirect on every request: http to https, the bare domain to www, a missing trailing slash to the canonical URL. A monitor that treats every 301 or 302 as a failure alerts on the very first check of a site that is working perfectly.

Barkme follows redirects and judges the response at the end of the chain. A 2xx or 3xx there counts as up. A 4xx or 5xx, a redirect loop, a timeout, or a DNS or TLS failure on any hop counts as down.

There is one consequence worth knowing. A monitor judges status codes, not content, so a redirect to the wrong place still passes if the wrong place answers 200. The most common version of that, a lapsed domain now pointing at a parking page, is what domain expiry monitoring is for. For everything else, monitor the URL your visitors actually land on, the one at the end of the redirect chain. It saves a hop on every check, and the response time you see is the page itself, not the page plus the redirects in front of it.

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 on recovery. Barkme's Linear and Trello channels open an issue or card when an incident starts, and add the recovery time and total downtime when the site comes back, so whoever picks it up can see at a glance that the site is already fine. The ticket stays open on purpose, until someone has looked at the cause. The alert nobody read explains why.

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.