Every status page lies to you a little

I didn't build DownDr because I wanted another dashboard. I built it because I kept wasting the same hour.

Something would start failing in production. I'd assume it was my code, because that's usually the safest assumption to make. I'd check logs, redeploy something, compare commits, rotate API keys, and slowly convince myself I'd introduced a bug.

Eventually I'd open the provider's status page. OpenAI was degraded. Or Cloudflare. Or Stripe.

The frustrating part wasn't that services go down — that's inevitable. The frustrating part was realizing I'd spent forty minutes debugging a problem that was never mine.

So I started building a small monitor that watches the external services my applications depend on. I thought the difficult part would be polling lots of APIs. It wasn't. The difficult part was learning that status pages don't always tell the truth in the way developers think they do.

Not because providers are dishonest. Because status pages answer a different question than developers are asking.

Lesson 1 — There isn't one "status page"

When I started, I assumed everyone used Atlassian Statuspage. That assumption survived for about a day.

After adding more services, I realized the ecosystem is surprisingly fragmented. Today DownDr monitors more than 75 developer dependencies, and that requires roughly a dozen different adapters. Some providers use Atlassian Statuspage. Some use Status.io. Some publish RSS feeds. Some expose their own JSON. Some barely expose anything useful at all.

Every time I thought I'd found a standard, another provider broke it.

AWS was one of my favorite examples. Their health endpoint doesn't return UTF-8 — it returns UTF-16 with a BOM. Nothing is technically wrong with that, but it's exactly the kind of thing you don't expect until your parser suddenly starts producing garbage.

Docker Hub surprised me too. Its public status URL redirects somewhere completely different, because it's actually backed by Status.io. Mistral uses Checkly. GitLab uses Status.io. Others publish Incident.io feeds. A few services don't even expose a clean public feed at all.

The lesson was simple. There isn't a universal status page format. There are just enough similarities to fool you into thinking there is.

Lesson 2 — "Major outage" often doesn't mean the product is down

This was the biggest surprise.

Most Atlassian Statuspage instances expose an overall status indicator: Operational, Minor, Major, Critical. At first glance it looks like exactly what you'd want. Easy.

Except it isn't. That indicator is simply the worst component on the page. It isn't trying to answer whether the product works — it's summarizing the most severe component currently listed. That difference matters. A lot.

One evening, OpenAI declared a major outage. If you only looked at the headline, the obvious conclusion was: OpenAI is down.

Except it wasn't. Image generation had a serious incident. The API was still working. Chat was still working. Developers calling GPT-4o through the API could keep working normally while the status page still showed "Major Outage."

Anthropic produced something similar around the same time. Claude Code was having issues. The API remained operational. The homepage still showed "Major."

Those aren't mistakes. They're just optimized for provider communication rather than developer decision-making. As someone debugging an application, the question I actually care about is much narrower: can the dependency I'm using still serve requests?

That led me to change how DownDr interprets incidents. If a provider reports a major incident but some components remain operational, I classify it as degraded rather than down, and show which component is actually affected. Only a provider-declared critical incident — or a major outage where essentially nothing remains operational — is treated as down.

That single change eliminated a surprising number of false alarms.

Lesson 3 — Cloudflare is almost always degraded

This one made me laugh.

For days, my monitor insisted Cloudflare was degraded. Every single day. Eventually I assumed my parser was broken.

It wasn't. Cloudflare operates an enormous global network, and some point of presence somewhere is almost always under maintenance. Statuspage reflects that, so the aggregate indicator often sits at "Minor" even when there isn't an active incident affecting most users.

If I trusted the headline blindly, DownDr would spend half its life telling people Cloudflare was degraded. That obviously isn't useful.

So I changed the logic. A minor status without an active incident becomes operational. Real incidents still surface immediately; background maintenance doesn't.

Lesson 4 — "Current events" aren't always current

AWS taught me another lesson. Their Current Events feed contained regional advisories from months earlier. They weren't active incidents. They weren't new. They were simply... still there.

Without filtering, those old advisories looked like fresh outages. The fix wasn't another parser — it was accepting that stale data exists. Now anything obviously old is ignored. If an outage supposedly started months ago and never resolved, that's almost certainly historical information, not something that should wake a developer up at 2am.

The infrastructure mistake that forced a rebuild

Not every lesson came from provider APIs. One came from my own deployment.

Initially I assumed Vercel Cron would poll every five minutes. Then I read the documentation more carefully. The Hobby plan runs roughly once per day — which is perfectly reasonable, unless you're building a five-minute monitoring system.

That forced me to redesign the polling architecture. Polling moved elsewhere, and the design actually became simpler: every provider is polled once, the result is stored once, and every subscriber reads from that shared state. No per-user polling. No duplicate work. It ended up being a better design anyway.

One rule kept the entire catalog under control

As the service list grew, I kept running into the same question. Should Redis be included? RabbitMQ? Kafka? Jenkins?

Eventually I realized I needed one simple rule: monitor dependencies, not technologies.

Your application might depend on Redis Cloud. It doesn't depend on Redis as a concept. There's no universal "RabbitMQ is down" — only your RabbitMQ, and that's an infrastructure problem, not a provider problem.

That single distinction kept the catalog from turning into hundreds of random technologies that no status monitor could ever answer correctly.

The interesting question isn't "what's the status?"

Building this changed how I think about outages.

The official status page answers one question: what does the provider want to communicate? Developers usually want something different: should I keep debugging my own code?

Those aren't the same question. That's the gap I ended up building DownDr to fill — not to replace official status pages, but to answer the question they were never designed to answer: is it them, or is it me?

If you rely on services like OpenAI, AWS, Stripe, Cloudflare, Vercel, Supabase, or Docker Hub, you can try DownDr. The public status board is available without signing in, and if you create an account it can notify you when the services you actually depend on change state.

I'd also love to hear from other developers: what's the strangest behaviour you've seen from a provider's status page?