How often a site needs checking: 140 monitors and 489 incidents measured

We looked at the polling frequency of the 140 active monitors in our system as of 27 August 2026:

The distribution is bimodal: almost everyone picks either an hour or five minutes, and virtually nobody picks anything in between. That does not look like choosing an interval to fit a job — it looks like taking the default, or the extreme available on the plan.

By check type: HTTP 114 monitors, ping 8, SSL 7, API 5, port 2, DNS 2, domain 2.

Sampling caveat: these are our users, not the monitoring market. At 140 monitors large differences are visible and fine ones are not.

Over the same period 489 incidents closed with a known duration. The distribution:

The median is 45 minutes. But the left tail matters more: one outage in four fits inside five minutes, and more than a third inside ten.

Short outages are not trivia to be waved away. An application restart, an exhausted connection pool, a bad deploy followed by a rollback — all fit inside minutes, and all mean that some users got an error at that moment.

Put the two previous sections together. If an outage is shorter than the polling interval, the chance of catching it is proportional to duration over interval. Estimated against our own incident distribution:

So forty percent of monitors are configured such that they will, on average, miss more than forty percent of outages. Not notice them late — miss them entirely: the outage begins and ends between two checks, and nothing is left in the history.

How the estimate was computed and why it is optimistic. This is arithmetic, not a measurement: it assumes an outage begins at a random point in the polling cycle. Reality is worse for two reasons. First, an incident is usually declared not on the first failure but after several consecutive ones — so a short outage must survive several intervals to enter the statistics at all. Second, the distribution itself is built from outages that were noticed; those already missed by infrequent polling never entered it. The true miss rate is higher than the computed one.

A simple rule follows from the data: choose the interval by which outage you cannot afford to miss, not by habit and not by the ceiling of your plan.

1. If availability itself is what matters — a brochure site, a landing page, documentation — an hour is enough. You will see a multi-hour outage, and a five-minute one probably does not concern you.
2. If an outage costs money — checkout, cart, a customer-facing API — an hour will not do. Five minutes catches 87% of outages; one minute, 98%.
3. Do not mix unlike things at one interval. Most projects have one or two genuinely critical endpoints and a dozen secondary ones. Put a minute on the first and an hour on the rest, rather than averaging.
4. Check the incident declaration threshold. If it requires three consecutive failures, an hourly interval means an outage must last three hours before you are notified. That is a separate setting, and it is often forgotten.

To see how this works and set up your own checks, use monitoring.