OutageDeck
One status page for every service your stack depends on
46 followers
One status page for every service your stack depends on
46 followers
OutageDeck reads official machine-readable status feeds from cloud and SaaS vendors, then turns them into one dashboard, alerts, history, a free JSON API, RSS feeds, badges, and an MCP server. Paid plans can add private Statuspage or Instatus providers, including a team's own products. No crowdsourced reports or synthetic probes.
Free Options
Launch Team / Built With
Render Sandboxes: a computer for every agentRun untrusted code safely. Idle sandboxes cost nothing
Promoted
@kerolos_atallah Congrats for launch🙌 Integrating an MCP server so AI coding agents check vendor status before blindly rewriting code is a brilliant, Is there a public status page for OutageDeck itself so users can verify if OutageDeck is up during a massive multi-vendor cloud outage?
Thanks Priya. Yes, it’s at https://outagedeck.com/status
It checks the site, database, and whether provider ingestion is still refreshing on schedule. There’s also a machine-readable endpoint at https://outagedeck.com/api/health, which returns 503 if the database is unavailable or ingestion has gone stale, so teams can point an external monitor at it.
The honest limitation is that the status page runs on the same deployment. If OutageDeck itself is completely unreachable, the page will be unreachable too rather than showing red. I call that out on the page instead of pretending self-monitoring fully solves it. A separately hosted external check is the next step.
Small launch-day engineering note.
I found a nasty edge case in Statuspage-compatible feeds this morning: a provider's page timestamp can move backward after recovery. That let an old degraded row outrank a fresh operational check. I fixed the ordering, deployed it, and reran ingestion before trusting the record again.
Then Sentry opened a real US error-ingestion incident today. It is a good example of why status context matters: a quiet error dashboard can look like a healthy deploy while events are sitting in a backlog.
Until the backlog clears, I would keep local logs and request IDs, avoid redeploying only to make telemetry look green, and use a second health signal for alerts.
Official Sentry update:
https://stspg.io/tcdgnyx93p0q
Normalized timeline:
https://outagedeck.com/incidents/sentry-delayed-error-ingestion-in-our-us-region-2026-08-12?utm_source=producthunt&utm_medium=comment&utm_campaign=producthunt_sentry_update
The product lesson for me: source event time and observation time are different facts. Status software needs both.
Update: Sentry marked this resolved at 14:48 UTC. The backlog has been processed.
Correction to my launch note: I should not have said zero false positives. OutageDeck mirrors what vendors publish. Their feeds can be delayed, incomplete, or wrong, so the product provides traceable vendor evidence, not certainty. I am also removing fixed provider counts from mutable listing copy because the catalog changes.