UptimeRobot Alternative from Germany

What does a five-minute interval mean for time to detection?

That an outage goes unnoticed for two and a half minutes on average and five in the worst case. Adding the usual confirmation run that guards against a single failure, mean time to detection is seven and a half minutes and the maximum is ten. Only then do alerting, response and remediation begin.

These numbers only make sense against the monthly downtime budget. 99.9 per cent availability allows 43 minutes of downtime per month, 99.95 per cent allows 22 minutes, and 99.99 per cent allows 4 minutes and 23 seconds. A checking regime that averages seven and a half minutes to detection cannot measure the last of those three commitments — the measurement error exceeds the entire budget.

This is not a theoretical objection. Anyone publishing a percentage to customers should gather it with a method whose resolution is considerably finer than the commitment. As a rule of thumb: time to detection should be at most one tenth of the monthly budget. For 99.9 per cent that is four minutes, for 99.95 per cent two, for 99.99 per cent about twenty-five seconds.

The second half of the calculation is more often overlooked: detection is only the first term. After it come alert delivery, the response time of whoever was woken, and the remediation itself. Starting from ten minutes of detection consumes half the budget of a 99.95 per cent commitment before anyone has even typed a password.

The counter-check is worth making too. A shorter interval is not better in every case: it increases load on the checked service, and it increases false alarms when checking happens from only one direction. A short interval makes sense precisely where a commitment exists — and a long one everywhere else.

When does a basic status page stop being enough?

As soon as it needs to communicate something that did not come from a check. A status page derived from monitoring can reliably show what was measured: reachable or not. It cannot readily announce maintenance, explain an upstream provider’s outage, appear in two languages, or model an approval step before something goes public.

The transition usually becomes noticeable at the same point. An upstream provider has an incident — the payment processor, the mail service, a data centre. Your own checks are green because your own application is running, but customers cannot pay. On a page that only reflects measurements there is no way to express that state. Support then answers the same question a hundred times individually.

The second recurring case is planned maintenance. It is not an outage but an announcement; it has a window and affects specific components. It must be visible beforehand, override the state while it runs, and afterwards disappear from the availability calculation without a trace. That is a process of its own, not a side effect of a check.

The third is subscriber management. Once a three-figure number of people want notifying, requirements appear that have nothing to do with monitoring: selecting individual components rather than all, double opt-in, an unsubscribe link, deliverability, and a record of who received what and when. That is where a status page stops being a view and becomes a tool in its own right.

As long as none of those three cases arises, a basic status page is perfectly sufficient — and the effort of replacing it with something larger would not be justified.

Why does the number of check locations matter more than the number of checks?

Because it decides whether a failure is interpretable at all. A failed request from a single direction can mean the service is down — or that the path to it was disrupted. Both look identical. Only comparing several simultaneous vantage points turns a measurement into a statement.

The usual workaround is the confirmation run: after the first failure, check again, and only then alert. That filters brief blips effectively and simultaneously doubles time to detection. It does not answer the actual question, because both runs take the same path — if the route is disrupted, both fail.

Multiple locations invert this. If Frankfurt and Helsinki fail simultaneously and Vienna does not, a network segment is the likely cause. If all three fail, it is the service — immediately, with no waiting period. A majority rule therefore delivers both fewer false alarms and shorter time to detection, which a confirmation run can never do.

In practice that means setting priorities differently from what tier tables suggest. Four hundred checks from one direction are worth less for an availability statement than forty from four directions. The number the tiers are built on is rarely the number that determines the quality of the statement.

Why does the number of checks grow faster than their usefulness?

Because checks get created and almost never removed. An estate that has grown over two years typically contains entries for decommissioned test environments, migrated domains and services that no longer exist. They report nothing but consume an allowance — and worse, they clutter the very list somebody has to search during an incident.

The mechanism is harmless and therefore persistent. Creating a check takes a minute and everyone who joins does it. Deleting one requires certainty that nobody needs it any more, and that certainty is rarely worth the time it takes to establish. The estate grows monotonically because the effort is distributed asymmetrically.

The visible consequence is the tier jump triggered not by new services but by old ones. The invisible one matters more: an overview of three hundred entries, eighty of which monitor nothing, is harder to read during an incident than one of two hundred and twenty. And that is exactly when it matters how quickly somebody sees which entries belong together.

A simple procedure helps and costs half an hour a quarter: list every check that has had no state change at all in the last ninety days. Those are either very stable services or dead entries, and the address usually makes the difference obvious. Noting which check belongs to which status page component at the same time also surfaces the components with no check — the other common gap.

A migration provides the occasion anyway. So it is worth not copying the estate across but justifying it: for each entry, answer once who is affected when it fails. Entries without an answer do not need moving.