Methodology
How Heartbeat measures, and how we monitor ourselves
A status page is only worth reading if you know what its numbers mean. This page states exactly what we check, where from, what counts as an incident, and how often our own checker misses a run. Last computed 2026-10-20 05:21 UTC.
What one check is
Every 10 minutes one request goes to each of the 25 APIs, a plain HTTPS GET with no key and a 12-second timeout. A result passes only if all three hold: the status code is 200, the body parses, and the body has the fields a real answer would have (for example a price for a crypto API). A 200 with an error page counts as a failure.
Response time is measured from sending the request to receiving the full body. It includes DNS, TLS and transfer, as seen from one server.
Uptime
7-day uptime is passed checks divided by all checks in the trailing 7 days. A missed monitor run is not counted as an outage of any API, it is simply missing data, and the table above shows how often that happened.
What counts as an incident
Down: two consecutive failed checks open an incident, so about 10 to 20 minutes of failure. The first passing check closes it. One isolated failure is stored and lowers uptime, but is not an incident.
Slow: two consecutive passing checks that are both above 1,500 ms and above 3 times that API's own 7-day median. Naturally slow APIs are not flagged for being slow.
Limits you should know about
All checks run from a single server in Sweden. An API that is reachable from Europe may be down for users elsewhere, and the other way round. A failure in our own network path would show up as many APIs failing at once; the Heartbeat Index page makes that visible.
Free public APIs may rate-limit or block cloud IPs. We keep to one request per API per run, far below any published limit.
Where the raw data is
Everything shown on this site is available as JSON. Every result is stored, none is deleted or edited, and incidents link to a post-mortem with the failing results.