How OutageDeck reads and reports vendor status

Every status comes from the vendor's official source

OutageDeck tracks 172 cloud and SaaS providers, and every one of them is read from an official machine-readable status source published by the vendor itself: the same feed that powers the vendor's own status page. Nothing is guessed, probed, scraped from marketing pages, or crowd-reported. Every provider page links to the official source it was read from, so any status shown here can be verified against the vendor in one click.

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.

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 provider's own published updates, reproduced with their original timestamps and linked back to the official entry. 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 data was last checked. Alerts fire only on real state changes detected between checks: 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 10-minute checks 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.

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.