Services Articles About us

Methodology

How DownBits decides that something is down

A status page is only worth reading if you can check its working. This page describes exactly what we measure, how often, from where, and where our measurements stop being reliable.

77
Services tracked
101
Active probes
24
Vendor status feeds
5 min
Probe interval
1,309
Checks, last 24h
21
Incidents, last 30d

Three signals, ranked by how much we trust them

Most outage trackers use one source. We use three, and every status page says which one produced the reading you are looking at.

  1. 1. The vendor's own status page

    Where a service publishes a machine-readable status feed, we read it every 5 minutes. This is the strongest signal available: it comes from the people running the service, it is component-level, and it carries their own incident history. We currently ingest 24 such feeds, and we link each vendor's status page from its DownBits page so you can check us against them.

  2. 2. Our own HTTP probe

    Every 5 minutes we make a real HTTP request to the service and record the status code and how long it took. A single failed check never marks a service down — we require repeated consecutive failures, because one dropped packet is not an outage. Redirects count as reachable. So do 401 and 403 responses: a service that refuses us is still a service that is running.

  3. 3. Reports from people using it

    Anyone can report a problem without registering. Reports are compared against a rolling seven-day baseline for that specific service, so a spike means "unusual for this service" rather than crossing a fixed number that would be meaningless for a small portal and trivial for a global platform.

Where our measurements stop being reliable

This is the part most status sites leave out.

Region-restricted portals

A number of Indian government and exam portals refuse connections from outside India, or route so slowly that a probe times out, while working perfectly for someone sitting in Ranchi or Patna. A probe that treated those timeouts as outages would publish a portal as permanently down, which is worse than publishing nothing.

So for those services we report "unreachable from our vantage point" and say so plainly, rather than asserting an outage. When our probe and a cluster of user reports from inside India agree, that is a much stronger reading than either alone — and that is what we show.

  • Response time is measured from our probe to the service. It does not include your connection, your DNS resolver, or browser rendering.
  • Uptime percentages are computed from our own checks only. They are not the vendor's contractual SLA and should not be read as one.
  • We check the front door. A service can answer our probe while a feature you need is broken — which is why component-level data from the vendor takes precedence.
  • Incidents shorter than ten minutes are not written to the history, to keep the archive readable.

Data retention

Individual checks are kept for seven days at full resolution, then compacted into hourly availability and latency figures that we keep indefinitely. That is what the 7-day and 30-day charts read. Incident records are never deleted.

Corrections

If DownBits is showing something wrong about a service you operate, tell us and we will fix the monitor or remove the reading. We would rather show nothing than show something false.