How it works

Last updated 10 November 2026

Everything Broken Today shows follows the rules on this page. They are the same for every service, and the page is updated when the code changes. In short: the status always comes from the company's official status page; our own checks and visitors' reports are shown next to it and never change it.

Where the status comes from

Each of the 387 services is mapped to its company's official public status page. 340 of them publish the common Statuspage format (also used by incident.io-hosted pages); for the rest - AWS, Microsoft, Google, Apple, Slack and others - we read the company's own status feed with a reader written for it. When a company moves its status page, the old address stops answering or returns a web page instead of data; the service then shows "Source unavailable" until we update the mapping. The sources page lists every mapping and whether it answered recently.

How often

• Every status page is read every 2 minutes. A Statuspage page's list of recent incidents is read every 15 minutes, and at once when the set of open incidents changes. We keep the 25 newest incidents of each service from that list.
• A page that has not answered for 10 minutes is shown as "No data" rather than its last known status.
• A page that keeps failing is retried every cycle for about 30 minutes, then every 15 minutes, and after about 12 hours once an hour.

What the statuses mean

• Operational - the company reports no problem.
• Maintenance - planned work is in progress and nothing else is wrong.
• Degraded performance - the company reports a minor incident, or one of its components is slow or failing while the page as a whole says everything is fine.
• Partial outage - the company's page or an open incident says major impact.
• Major outage - critical impact.
• No data - we could not read the page for 10 minutes.

The status of the whole service is the page's own overall indicator, raised by the impact of any open incident. One broken component on an otherwise green page lifts the service to Degraded only: Cloudflare, for example, lists hundreds of data centres, and one re-routed location is not a partial outage of Cloudflare. Group headings on a status page are ignored.

Which incidents count

• An incident the company leaves open with no update for over 14 days is shown on the service page as a long-running incident but does not change the status - some vendors leave incidents open for months.
• Scheduled maintenance is shown separately and is not counted as an incident in the reliability figures or the monthly reports.
• Incident names and updates are the vendor's words; we only replace long dashes with hyphens.

Quiet status pages

Some companies post only their largest problems, and some stop using their status page altogether. When a Statuspage page has not listed a new incident for over 180 days, its service page says so next to the green light, and the sources page marks it. Every service page shows the date of the last incident the company posted.

Our own checks

For 35 large services we request a public address ourselves every 2 minutes from a server in Germany - usually the website or an API endpoint that answers without an account. Any answer below HTTP 500 counts as up (a "please log in" answer still proves the service is reachable); a timeout, a connection error or a server error counts as a failure. A service is "not answering" after 2 failed rounds in a row. If most services fail in the same round, the round is treated as a problem on our side and ignored. The last 2 hours of checks are kept in memory and shown as a fact on the service page; they never change the status.

Visitors' reports

"Not working" and "Works for me" on a service page are counted for 24 hours and shown as counts. One answer per service per visitor every 30 minutes counts, and known crawlers are ignored. Reports never change the status - anyone can press a button - but many "not working" reports while the vendor still says "Operational" are worth knowing about, so the page says so.

Seen before the vendor

When a company posts a new incident, we look back once: did our own check of that service start failing (at least 2 failed rounds, still failing or recovered at most 30 minutes before the post), or did the third "not working" report arrive within 30 minutes? If that happened between 3 minutes and 3 hours before the company posted the incident, the incident is marked "seen before the vendor" with the time and the source. It is a statement about timing only. All of them are listed in seen before the vendor.

Incident pages and history

We record every incident we see from 15 October 2026 on, plus older ones that were still listed on the status pages then, and the minutes each service spent in each state every day. Each incident gets a permanent page with the vendor's last update, its duration, similar incidents of the same service (shared affected component or wording) and an "at a glance" summary: how its duration compares with the median of that service's other resolved incidents, how many incidents came in the 30 days before it, and whether a root cause analysis was posted. Those summaries are computed by these rules, not written by a person or an AI.

Durations run from the vendor's start time to its resolution time. When a vendor marks an incident resolved without a time, or backdates the start, we use what the vendor published.

Postmortems

An incident counts as explained when an update on the status page is marked "postmortem", links to a postmortem, incident report or root cause analysis, or is a root cause write-up of over 500 characters that is not a promise. "A root cause analysis will be shared" counts as promised. A postmortem published only on a blog and never linked from the status page is not seen. See who explains their outages.

Possibly the same cause

When Cloudflare, AWS, Google Cloud, Azure or GitHub has an open incident, services whose problems began between 30 minutes before and 3 hours after it are listed as "possibly the same cause". That is a match in time only - we cannot see the dependencies between companies.

Alerts and posts

E-mail, chat and browser alerts go out when a service you chose goes from fine to Degraded or worse, when it gets worse, and when it is fully operational again - never more than one "problem" message per 30 minutes per subscription. Our Bluesky and Mastodon accounts post major outages, and partial outages of the most searched services, once they have lasted 4 minutes.

What we cannot see

• Problems the company has not posted yet, and problems it never posts.
• Problems that affect only your account, network, region or device.
• Parts of a service that its status page does not list. Some pages cover several products; some cover only one region.

Found something that does not match these rules? Use "Something wrong on this page?" on the page in question or write to hi@brokentoday.com. More about us and how we handle corrections is on about.