DEV Community: Kerolos Atallah

I read 172 official status feeds every 10 minutes. Here is what is quietly broken in them.

Kerolos Atallah — Wed, 05 Aug 2026 17:00:52 +0000

For the last few weeks I've had a cron job reading the official status feed of 172 cloud and SaaS providers every ten minutes. Not scraping their HTML, not counting tweets, just reading the machine-readable source each vendor publishes about itself.

I wrote about the first version of this in July, when it was 96 providers. This is what another 76 vendors and a month of collected data added, and most of it is stranger than the first batch.

I expected the hard part to be scale. It wasn't. The hard part is that "the official status feed" is not one thing, and several of them are quietly broken in ways their own vendors seem not to know about.

There is no standard, and it isn't close

Statuspage's /api/v2/summary.json is the closest thing the industry has to a convention, and it covers most but not all of what I track. The rest need their own parsers. Google publishes a dashboard incidents.json in its own shape, AWS has a health event feed, Azure emits RSS, Slack has a bespoke API, Oracle Cloud has a region-by-service matrix, Status.io has its own API, and Instatus serves a near-copy of Statuspage's format.

That last one is the instructive case. Instatus exposes /api/v2/summary.json at the same path as Statuspage, and it parses, but it omits the components array, page.updated_at, and the incident archive. A parser written against Statuspage will happily consume it and conclude that a vendor with a live outage has no components and nothing wrong. Compatible-looking is worse than incompatible.

AWS ships its status feed in UTF-16, big-endian

https://status.aws.amazon.com/data.json redirects to health.aws.amazon.com/public/currentevents and returns a body that starts with the bytes FE FF.

That's a UTF-16 big-endian BOM. Not UTF-8. Not even the little-endian UTF-16 you'd occasionally expect from a Windows toolchain. response.text() in a browser or Node will not give you usable JSON, and neither will a naive UTF-8 decode. You get a string of interleaved null bytes and a parse error that looks like the endpoint is down.

Everyone consuming this feed has independently discovered this and written the same three-branch decoder. It has apparently been this way for years.

Stripe's status JSON has said "all services are online" since February 2024

$ curl -s https://status.stripe.com/current
{"statuses":{"api":"up","webhooks":"up",...},
 "largestatus":"up",
 "message":"All services are online.",
 "time":"February 09, 2024 @ 06:08PM +00:00"}

HTTP 200. Well-formed JSON. Reassuring message. And a timestamp from over two years ago that has not moved since. I re-ran that curl the morning I published this, and it still says exactly that.

Stripe's human status page is fine. They migrated, and the new one works. The old JSON endpoint was simply never turned off, so it still answers, still says everything is up, and will keep saying that through any incident you care about. If you wired a dashboard to it in 2023, it is still green today and it means nothing.

This is the single strongest argument I know of for not trusting a status endpoint you haven't checked the freshness of. It's also why I refuse to list Stripe at all rather than serve a fossil. A green light that cannot turn red is worse than no light.

Vendors forget to close incidents

At the time of writing, AWS still lists two open events in its own health feed, one in me-central-1 and one in me-south-1, opened on 1 and 2 March. That is over 3,700 hours each, about 157 days. Narrow the question to incidents that opened in the last 30 days and the longest is a Telnyx incident at 506 hours, nearly 21 days, followed by a KnowBe4 purchasing page at 463 hours.

I don't think these are month-long outages. I think they're incidents someone opened, fixed, and never went back to close. But there is no way to tell that from the outside, and the vendor's own page still says open, so any honest aggregator has to either report it as open or start silently overriding vendors about their own systems. I report it, and I label the duration "stayed open" rather than "downtime", because those are not the same claim.

The genuinely strange ones

Cisco Duo publishes 847 components with 94 distinct names. Core Authentication Service appears 80 times, once per deployment shard. If you build your lookup with a naive new Map(components.map(c => [c.name, c])), last wins, and 79 shards reporting an outage get masked by one healthy one at the end of the array. You have to take the worst status across every occurrence.

ClickHouse has a component named AWS us-west-2, with two spaces. Match on the exact string or you will never map it.

NetSuite once published its internal telemetry as public incidents. Real entries, in the real feed, titled _system_metadata:eyJ1cHRpbWUi…. Base64-decode that and you get {"uptime":"99.99","requests_served":…}. Somebody's monitoring pipeline was writing to the customer-facing incident stream.

Several status pages block non-browser clients. 8x8's WAF returns 403 to anything without a browser user-agent. Okta's status API returns 401. A status page that only a human can read is, for automation purposes, not a status page.

No consumer carrier publishes one at all. Vodafone, AT&T, Verizon, T-Mobile, BT, Orange, Telstra: I checked all of them. There is no official machine-readable status feed for any major consumer telecom operator. Every site that appears to show you one is showing you crowd reports.

What a month of this actually looks like

Across the last 30 days, the 172 providers logged 1,455 incidents between them, and 151 of the 172 had at least one. 369 were rated major or critical by the vendor themselves: 267 major, 102 critical, against 1,084 minor. Telecom and connectivity was the busiest category with 305, then cloud and infrastructure at 219, then developer tools at 196, then AI at 147.

The distribution is the part I found most useful. Most of it is minor, and most of what a status page publishes is noise relative to your stack. The question that actually matters during an incident isn't "what's broken somewhere". It's "is anything I depend on broken, right now, according to the vendor itself".

The takeaway I'd want if I were reading this

If you consume vendor status programmatically:

Check the timestamp, always. A stale-but-green endpoint is the failure mode you will not notice.
Assume component names repeat. Aggregate to worst-status, never last-wins.
Don't trust a compatible-looking payload. Assert that the fields you need exist.
Decode by bytes, not by assumption. Check for a BOM before parsing.
Treat "open" as "the vendor hasn't closed it", which is not the same as "still down".

I turned all of this into OutageDeck, which reads those 172 feeds every ten minutes so you don't have to write the decoders. But honestly, the five rules above are most of the value. If you're building this in-house, that's the list I wish I'd had.

Happy to answer anything about specific feeds in the comments. If there's a vendor whose format has broken you in an interesting way, I'd like to hear it.

There's no standard status page, and other lessons from tracking 96 providers

Kerolos Atallah — Sat, 18 Jul 2026 01:50:09 +0000

Your Slack won't load. Is it you, your VPN, the office wifi, or Slack? You open Slack's status page and it's green. It's often green while you're clearly down, because a company updates its own status page after it confirms an incident — not the moment you feel it.

I spent the last few months building OutageDeck, which reads the official status source of 96 cloud and SaaS providers and folds them into one place. I assumed the hard part would be the frontend. It wasn't. The hard part was that "official status" is a swamp. Here's what I found in it.

The short version:

There is no standard status format. Statuspage is common, but the tail is bespoke — Google, Slack, Heroku, Azure over RSS, and AWS in UTF-16.
Providers' own timestamps lag, sometimes by days, so you can't compute uptime from them.
Some official feeds are stale fossils, or model thousands of instances, so "is it up?" has no single answer.
Official status is authoritative but late — which is the whole reason crowd-sourced "is it down?" sites exist.
All of this pushed me toward a deliberately tiny backend: one Next.js app and a Postgres database, no queue, about $55/month.

There is no standard

Atlassian Statuspage is the closest thing to a common language. Around 89 of my 96 providers expose a Statuspage-style summary.json and incidents.json, and one adapter reads all of them. Some providers don't even run Statuspage but copy its shape anyway — incident.io serves a Statuspage-compatible endpoint on each customer's own domain, so Notion and Linear parse with the exact same code.

Then the long tail starts. Google publishes an incidents.json in its own format (shared across Cloud, Workspace, and Firebase). Slack has a bespoke API. Heroku is on the fourth version of its own. Azure only offers RSS. AWS ships an event feed encoded in UTF-16 with a byte-order mark, which silently breaks any parser that assumes UTF-8. "Just read the status page" turned into six adapters and a pile of encoding checks.

The timestamps lie

My first uptime numbers were nonsense, and it took me a while to see why: I was computing them from each provider's own captured_at timestamp, and those lag. One provider's was days behind at one point. If a feed says a state was "captured three days ago," you can't tell whether the service was down for three days or the timestamp is just stale.

The fix was to stop trusting upstream time entirely. Every observation is stamped with my check time, and uptime is computed from when I saw a state, not when the provider says it happened. The corollary matters too: if my own poller has a gap — a deploy, say — I don't backfill it as "up." Any gap longer than 30 minutes is recorded as no data, because inventing green is worse than admitting I wasn't looking.

Some official sources are fossils

A few providers technically have a machine-readable status endpoint that you still can't use. Stripe's legacy status JSON has been effectively frozen since 2024; it will cheerfully report that everything is fine, forever. Salesforce's status API models nearly 3,900 separate instances, so "is Salesforce up?" depends entirely on which pod your org sits on.

For sources like these, the honest move is to not ship them until I have something I'd trust myself. That's why they're still missing from the list. I'd rather explain a gap than fake a green light.

What the feeds did to the backend

Two properties of these feeds shaped the whole system.

They re-send their full recent history on every poll, and an unchanged upstream just re-stamps the same row. So the raw data can't reconstruct history — you can't diff yesterday back out of it. Instead of trying to rederive it later, I roll each poll's observations into daily per-provider buckets at write time. I also skip writing rows that didn't change; an early version rewrote identical rows every run and burned the database's IO budget for nothing.

I run two schedulers on purpose: a 10-minute cron as the primary, and a 30-minute job as a backstop. So runs overlap. Rather than add a queue or a lock service, I let Postgres be the referee. Alert deliveries are claimed with a unique constraint before anything goes out:

-- alert_deliveries has: unique (subscription_id, event_key)
insert into alert_deliveries (subscription_id, event_key, payload)
values ($1, $2, $3)
on conflict (subscription_id, event_key) do nothing;
-- 1 row inserted  -> I won the claim, send the alert
-- 0 rows inserted -> another run already has it, skip

The insert that survives the unique index is the one that sends; the overlapping run writes nothing and moves on. No queue, no exactly-once framework, no dead-letter topic. The uptime writes take a per-entity advisory lock for the same reason. The whole thing is one Next.js app and a Postgres database, no background workers, running on about $55 a month.

So I built the thing I wanted

OutageDeck is the result: one place to check whether 96 major providers are up, sourced from each one's official status feed rather than from user complaints. It's free to use and there's no signup to check a provider. Under the hood it's the pipeline above — official-only, honest about timestamps, and clear when it just doesn't know yet.

If you want more than a webpage, there's a public JSON API, embeddable SVG status badges you can drop in a README, RSS feeds per provider, and an OpenAPI 3.1 doc.

Two honest caveats: incident history only goes as deep as each upstream feed exposes, so this isn't a system of record for ancient outages; and I'm still adding providers as I find sources I actually trust.

Try it, and stay in the loop

Check any provider, free, no signup: outagedeck.com
Want a heads-up when something breaks? Free email alerts for up to 5 providers; paid plans add Slack, Discord, and webhooks.
Prefer a digest? I send a short weekly rundown, This week in cloud outages — you can subscribe on the site.

I'd genuinely like to know two things in the comments: which providers you'd want tracked next, and what would make the API useful inside your own monitoring. I'll be writing up more of the internals (the uptime rollups, the fail-open API) — follow along if that's your thing.