Skip to content
OutageDeck

Methodology

How OutageDeck reads and reports vendor status

A status product is only as trustworthy as its sourcing, so the whole method is public. This page explains where every number on the site comes from, how often it refreshes, and what OutageDeck deliberately does not do.

Every status comes from the official source that publishes it

OutageDeck tracks 180 cloud and SaaS providers, and every one of them is read from an official machine-readable status source: the same feed that powers the status page the provider points its own customers at. Nothing is guessed, probed, scraped from marketing pages, or crowd-reported. Every provider page links to the source it was read from, so any status shown here can be checked against that source in one click.

A source is not always a page the provider owns. These are read from a parent company's page instead: Replicate on Cloudflare Status and SendGrid on Twilio Status. That is still first-party status, published by the company that operates the service, which is the distinction this page exists to draw. It is not the provider's own page, though, and OutageDeck does not blur the two: a hosted provider's page here names where its reading came from, the API and the MCP server carry the same attribution, and an incident the host wrote is never credited to the provider.

This also defines the catalog's boundary: a vendor without an official machine-readable feed is not tracked, no matter how popular it is, because the alternative is inventing data. When a vendor publishes one, it can usually be added quickly: request a provider.

The same boundary decides whether a parent's page counts. It qualifies when the company publishing it operates the provider and reports on it as a named component of its own service list. A reseller's dashboard, a hosting provider's page, or a third-party aggregator does not qualify, however current it happens to be, because the rule was never about finding a page that mentions the vendor. It is about reading a statement the party responsible for the service made about itself.

One vocabulary across every vendor

Vendors describe trouble in their own words, so OutageDeck translates each feed into one shared scale: operational, degraded, partial outage, major outage, maintenance, and unknown. The translation is conservative and mechanical; it never editorializes. When a vendor publishes many components, the service entries on its page mirror the vendor's own component statuses, and when the same component appears more than once in a feed, the worst reported state wins.

Incident timelines are the updates the source published, reproduced with their original timestamps and linked back to the official entry. Where a parent publishes a provider's status, the words are the parent's. OutageDeck adds ordering and history, not words.

Freshness and alerting

Every provider's feed is re-read about every 10 minutes, around the clock, and every page shows when its source was last read. Alerts fire only on real state changes detected between readings: a new incident, a lifecycle update, a resolution, or a provider-level status change. Re-reading an unchanged feed never alerts, and a newly added provider's historical backfill never alerts either; only incidents that started within the last 24 hours can trigger a new-incident notification.

How uptime is computed

Uptime history is OutageDeck's independent record of what each vendor reported, accumulated from those readings into daily UTC rollups. Two rules keep it honest:

  • Major and partial impact are reported separately. A regional or single-service event counts as partial impact, not a platform-wide outage, so one bad region never erases a vendor's record. The headline percentage is time free of major outages, with partial impact stated alongside it.
  • Durations measure reported time, not downtime claims. An incident's duration is how long it stayed open on the vendor's feed. Vendors sometimes leave incidents open for weeks; entries open past two weeks are annotated on the uptime strip rather than hidden, because editing the record would be worse than explaining it.

Uptime accumulates from the day a provider joins the catalog, and each page states its own tracking window. OutageDeck never backfills uptime it did not observe.

How the reliability roundups rank providers

Each category roundup compares providers over the 30 complete UTC days ending yesterday. Today is left out because it is not over: a figure that changes with the minute a page was built is not one two providers can be compared on.

  • Ranked only at 99% observed. A provider is ranked only when OutageDeck observed at least 99% of the 30 complete UTC days ending yesterday. That allows at most 7h 12m without a known status across the whole window. Time between readings too far apart to vouch for, and time the feed reported nothing usable, both count as unobserved.
  • Everyone else is listed, not dropped. Everyone else is listed with the reason they are not ranked, and with their own figures where they have any. A provider is never given a shorter window to make it fit, and never ranked against a longer record than its own.
  • The whole record or nothing. If a category's history cannot be read in full, nobody in it is ranked. A ranking built from the part that did arrive would put vendors in the wrong order.
  • Worst record first. Ranked providers are ordered by time free of major outages, lowest first, then by partial or regional impact as a share of observed time, then by name. The order uses unrounded figures, so two providers that both display 99.99% still sit in their real order.
  • Close records are called level. Unobserved time could have gone either way, so every figure has a best and a worst case. Providers whose ranges overlap, directly or through another provider, are grouped as level, and the page claims no order inside a group. Between groups the order holds even in the best case for the lower one. No position numbers are shown.
  • What the rule does not prove. Coverage says how much of the window OutageDeck saw. It does not say a vendor reported everything it should have, it is not an uptime guarantee, and 99% is a policy for this comparison rather than a measure of accuracy.

What OutageDeck deliberately does not do

  • No probing. OutageDeck does not send synthetic requests at vendors' systems. The record is what each vendor publicly committed to, which is exactly what you can hold them to.
  • No crowd reports. Crowd signals can be earlier, but they trade precision for speed. OutageDeck reports confirmations, not rumors, and says so plainly in its comparison with tools that choose differently.
  • No tracking of vendors without official feeds. Consumer carriers and several security vendors publish no machine-readable status; they stay out of the catalog rather than in it with invented data.
  • OutageDeck does not track itself in the catalog. The pipeline that would record an OutageDeck outage cannot run during an OutageDeck outage, so a self-tracked uptime strip would flatter us by construction. Instead, the status page reports live health and points at the machine endpoint an independent external monitor watches.

Corrections

If anything on this site misstates a vendor's published status or history, write to hello@outagedeck.com with the page and the official source, and it will be corrected. The same data is available for scrutiny over the public API.