Why we confirm three times before alerting you

There is a very quick way to ruin an alerting system: make it alert on everything. By the third false alarm at night, someone mutes the channel. And the day the site really goes down, the alert lands in a channel nobody watches any more.

That is why we do not alert on the first failure. Here is exactly what we do, with the real numbers, and what it costs.

What can fail in a check

Checking a site means requesting the page and seeing what comes back. When nothing comes back, it may be that:

• The site is really down.
• The network between our server and yours is having a bad moment.
• A firewall or anti-bot system is blocking us, and only us.
• DNS was slow to answer that one time.

From outside, all four look very similar. Only the first is an outage.

One check point, said plainly

We check from a single point: our server. We do not have a network of servers around the world, and we would rather tell you than have you find out.

The consequence is that a network problem between our server and yours can look like an outage. The defence is not to trust a single sample.

The sequence, second by second

On paid plans we check every 60 seconds. When a check fails:

00:00   fails                     → retried after 10 s
00:10   fails again               → failure 1 of 3, no alert
01:00   fails                     → retried after 10 s
01:10   fails again               → failure 2 of 3, no alert
02:00   fails                     → retried after 10 s
02:10   fails again               → failure 3 of 3: OUTAGE CONFIRMED

Each failure is retried ten seconds later, and only counts if the retry fails too. It takes three counted failures in a row to confirm the outage. If a check succeeds in between, the count goes back to zero.

To mark it resolved we require two good checks in a row. That way a site that comes back and falls over again does not send you a "resolved" and a "down" every minute.

What it costs

Confirming has a price, and it is fair to say so:

• You find out about two minutes later than with a monitor that alerts on the first failure. On the free plan, which checks every five minutes, it is about ten.
• An outage shorter than two minutes does not trigger an alert. If the site goes down and comes back between two checks, we do not see it. No tool looking from outside would, unless it checked every second.

In return, when we alert you, the site has gone at least two minutes without answering across six attempts in a row. That is no longer a blip.

And after confirming

Not every channel is equally intrusive, so not every channel alerts the same way:

• Slack, Teams, Discord, Telegram and webhooks get the alert as soon as it is confirmed.
• WhatsApp and email wait until the outage reaches 15 minutes (30 if the server does not respond at all). A five-minute cut is not worth waking you up.
• On WhatsApp, outages are also grouped in one message, two a day at most, and everything else goes into a Monday summary.

What the data says

In our own agency's portfolio, over the 90 days before 25 October 2026, we recorded 2,624 confirmed incidents. By cause:

Nine out of ten are timeouts. And a timeout seen from a single point cannot tell a dead server from a firewall blocking us. If you get an alert and your site loads fine from home, first check whether your hosting or your firewall is blocking our server.

Half of those incidents lasted nearly two hours or more (the median is 119 minutes). They are real outages, not blips: what confirmation filters out is exactly the one-minute cuts nobody cares about.

Sources

• MonitoraWeb production settings and the incident log of Monstruo Creativo S.A.C.'s portfolio, queried on 25 October 2026.