DEV Community: Kerolos Atallah

How to monitor third-party provider outages with two signals

Kerolos Atallah — Sat, 08 Aug 2026 19:36:00 +0000

When production starts failing, one of the first questions is also one of the most expensive to answer badly:

Is our application broken, or is a provider we depend on having an incident?

If the dependency is AWS, Cloudflare, GitHub, OpenAI, Stripe, or another cloud or SaaS vendor, there are two common approaches:

Read the provider's official status page.
Probe the service yourself.

Neither is enough on its own. A useful monitoring setup treats them as separate signals.

I am Kerolos, the founder of OutageDeck. I built it to normalize official status sources across 172 providers. This post explains where that signal fits, where it does not, and how I would combine it with synthetic checks.

Signal 1: what the provider says

An official status feed tells you what the vendor has acknowledged. It can provide details a black-box probe cannot:

the affected product or service
the region or customer segment involved
investigation and mitigation updates
the incident timeline
a recovery announcement

The problem is timing and scope. A provider may not publish an incident immediately. Its dashboard may say that the platform is operational while your account, region, route, or workload is failing.

Official status is valuable evidence, not an oracle.

Signal 2: what your users experience

A synthetic check asks a different question: can a request complete successfully from a location you care about?

Useful probes include:

an HTTP request against a critical endpoint
a DNS lookup through the route your users take
a small authenticated API transaction
a read and write against a non-production object or record
a check from more than one region

The probe should exercise the smallest safe transaction that represents the dependency. A TCP connection to port 443 proves very little if the API is returning errors after authentication.

Synthetic monitoring also has blind spots. Your probe may fail because of your own credentials, network, DNS, deployment, or test data. It can tell you that a path is broken, but not always who owns the fault.

The useful part is the correlation

Put the two signals together and the incident becomes easier to triage:

Provider status	Synthetic probe	Working assumption
Operational	Passing	No provider incident visible
Incident	Passing	Provider issue may not affect your path
Operational	Failing	Investigate your stack, but watch for delayed provider acknowledgement
Incident	Failing	Strong evidence of an upstream dependency incident

This is a starting point, not an automatic root-cause verdict. Region, service, and account scope still matter.

A small provider-status check

OutageDeck exposes a keyless read-only API, so a quick check can be as small as:

curl -fsS https://outagedeck.com/api/v1/providers/aws \
  | jq '{
      provider: .data.name,
      status: .data.currentStatus.code,
      headline: .data.currentStatus.headline,
      checked_at: .data.source.checkedAt,
      source: .data.source.officialUrl
    }'

For a dependency stack:

providers=(aws cloudflare github openai stripe)

for provider in "${providers[@]}"; do
  curl -fsS "https://outagedeck.com/api/v1/providers/${provider}" \
    | jq -r '[
        .data.name,
        .data.currentStatus.code,
        .data.currentStatus.headline,
        .data.source.checkedAt
      ] | @tsv'
done

The source timestamp matters. A green result from stale data should not be treated as healthy.

A matching synthetic check

The independent side might start with an HTTP request:

curl --fail --silent --show-error \
  --connect-timeout 3 \
  --max-time 10 \
  -o /dev/null \
  -w 'status=%{http_code} total=%{time_total}s\n' \
  https://your-critical-endpoint.example/health

In production I would add:

at least two probe locations
consecutive-failure thresholds to reduce transient noise
a dependency-specific timeout
a safe authenticated transaction where possible
separate alerts for probe failure and vendor acknowledgement

Do not make the provider-status lookup a hard dependency of the probe itself. If the aggregator is unreachable, the probe should still report what it observed.

A practical alert policy

I would route the combinations differently:

Probe fails, provider reports an incident: page the on-call owner with upstream context attached.
Probe fails, provider reports operational: page as an unclassified failure and keep polling the provider feed.
Probe passes, provider reports an incident: send a lower-urgency warning to the service owner.
Both pass: remain quiet.

That keeps a broad vendor incident from creating hundreds of disconnected alerts while preserving the evidence needed for triage.

What to record during the incident

For each signal, retain:

observation time
last successful check
region and service
response code or normalized state
provider source timestamp
incident identifier and updates

This makes the post-incident review much better. You can see whether your probes detected the problem before the provider acknowledged it, and whether your alert thresholds helped or slowed the response.

Try it without creating an account

I made a no-account dependency stack checker for the provider side of this workflow. Pick the vendors in your stack and it produces one shareable view of their official status signals. OutageDeck also exposes JSON, RSS, badges, CLI tools, and an MCP endpoint; free accounts can watch up to five providers by email.

I would like to hear how other teams correlate vendor status with their own telemetry. Which signal has been more misleading in your incidents: a provider dashboard that stayed green, or a synthetic check that blamed the wrong dependency?

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.