How our monitoring works
What our checks actually do, how often they run, what each status word means, and why a single failed request never puts a service on the down list.
One check, four measurements
Most uptime tools report a single number: Did the request succeed, and how long did it take. That collapses four genuinely different things into one, and the difference between them is most of the diagnostic value. Every check we run measures them separately.
- DNS resolution. How long it took to turn the hostname into an IP address, and whether it resolved at all. A failure here is a domain or nameserver problem, not a web server problem.
- TCP connection. How long it took to open a socket to that address. A refusal means nothing is listening; a timeout means something is swallowing the packets.
- TLS handshake. Whether a valid secure connection could be established, and how many days the certificate has left. An expired certificate is one of the most common causes of a site that is technically running and completely unusable.
- The HTTP response. The status code, the total time to first bytes, and how many redirects it took to get there.
The probe reads only the first couple of kilobytes of the response. That is enough to measure a real time to first byte without downloading a full page from every site on every pass, which would be an unreasonable thing to do to a hundred servers every 20 minutes.
How often
Every active service is checked every 20 minutes. That cadence is a deliberate compromise. Checking every minute would produce a finer record, and it would also mean sending sixty times more traffic to servers that never asked to be monitored. An check of a public home page is a negligible load on any of the services listed here and still catches every outage that lasts long enough for anyone to notice.
The cost of that choice is honest to state: An outage shorter than the gap between two checks can be missed entirely. A four-minute blip at 02:17 will not appear in our record. That is one of several reasons the user report chart sits next to the check data rather than underneath it.
What each status means
| Status | What it means |
|---|---|
| Up | The last check got an expected response in a reasonable time. |
| Slow | The service answered, but took longer than three seconds. Technically up, practically broken for a lot of people. |
| Checking | A check just failed and is being re-tested. Nothing is declared an outage on one failure. |
| Down | Two consecutive checks failed. This is the only status that opens a recorded incident. |
| Reports | Our check succeeded, but visitor reports are running well above this service's normal background level. Usually a partial or regional failure our probe cannot see. |
| No data | The service was added recently and has not been checked yet. |
Why two failures, not one
Networks are noisy. A single failed request can mean a transient route flap, a packet dropped between two autonomous systems, a load balancer restarting one node, or a rate limiter having a bad second. None of those is an outage, and all of them will fail one request.
So when a check fails, the probe pauses for a few seconds and tries again from scratch - New DNS resolution, new connection, new request. If the second attempt succeeds, the service is recorded as up and the first failure is discarded. If it fails too, the result is recorded as a failure, and an incident opens only when there are two consecutive recorded failures.
The practical effect: A service has to be genuinely unreachable for several minutes before this site will say so. We would rather be a few minutes late than publish that a company's service was down when it was not.
Bot walls, and why we retry with a browser
A number of very large sites sit behind bot management systems that silently discard any request whose user agent is not a mainstream browser. Our probe identifies itself honestly first, as IsItDownNowBot, with a link to a page explaining exactly what it is.
If that request fails in a way characteristic of bot filtering - A 403, a 406, a 429, or a connection that opens and then stalls without responding - The probe does not conclude anything yet. It works down a ladder of four rungs, and records which one produced the answer:
- Ask as ourselves. An identified request to the configured URL. This answers for almost every service.
- Ask as a browser. Same URL, mainstream user agent. Some bot managers discard anything else.
- Ask for something a filter leaves open. Usually
robots.txt- Which bot protection has to allow, because crawlers need to read it to know what is off limits. - Stop asking, and check the transport. Open a connection and complete a TLS handshake without sending HTTP at all. A firewall cannot selectively refuse that without refusing real browsers too, so a completed handshake proves there is a working server on the other end.
Rung four is the important one, and it is honest about what it proves. A completed handshake means the server is reachable and serving TLS - Not that the application behind it works. When a verdict comes from there, the status page says "transport only" beside the check rather than implying we fetched a page. It is weaker evidence, and it is far better than announcing that a healthy service is down because a firewall disliked our user agent.
How an outage is recorded
When two consecutive checks fail, an incident opens and its start time is set to the first of those failures, not the second - So the recorded duration reflects when the service actually stopped answering us, not when we became confident about it.
The incident stays open, with a running clock, until a check succeeds. At that moment it closes, the duration is calculated, and the peak user report volume during the window is attached to it. That record is permanent and appears in the service's history, in the global outage log, and in the RSS feed.
What user reports do and do not do
Reports appear on the 24-hour chart on every status page, feed the "most reported problems" breakdown, and can raise a service's displayed status to Reports - A visible warning that says, in effect, "our check is fine but a lot of people disagree".
They cannot do anything else. They never open an incident, never close one, never change the uptime percentage, and never appear in the recorded history. That separation is the whole design. It means the uptime number on this site is a measurement, and the report chart is a crowd - And you can see both without one contaminating the other.
What we cannot see
Being clear about this is more useful than pretending otherwise.
- Regional outages. We check from one network. An outage affecting one country, one continent or one ISP will usually not show here at all.
- Mobile app failures. Apps talk to different endpoints from the website. An app can be completely broken while the home page we check is perfectly healthy.
- Feature-level failures. Login broken, feed empty, checkout failing, messages not sending - None of that moves an HTTP status code on a home page.
- Short outages. Anything that resolves inside the 20-minute window between two checks.
Every one of those is exactly what user reports are good at catching, which is why both halves of this site exist. The methodology page goes further into how the numbers are calculated and what they are worth.