exit1.dev
Real-time uptime monitoring platform
Most dashboards poll every 30 or 60 seconds. It's simple and cheap. You refresh, you get the latest state, done.
I went the other way and made each check result stream to the browser the moment it finishes, over a WebSocket. Watching it is genuinely different. During a live incident you see checks fail in real time across regions, so "is it actually down or just down for me" becomes something you watch instead of guess.
The honest part is that streaming takes more engineering than polling to make reliable. A poll can't really break. A live connection can drop, go quiet, or sit there looking open while it's actually dead. So you build for all of it: reconnects, keepalives, and a clean fall back to a normal fetch the moment the socket goes, so you're never left staring at stale data. Do that work and it's rock solid. The complexity is the price of real-time, not a crack in it.
I'd build it again just for how it feels during a live incident. What I'm less sure about is whether most users would even notice, or whether polling is the smarter, boring default.
For something like monitoring, where do you land? Real-time worth the extra engineering, or not?
Watch a showcase of the live page here
When your API goes down, what's your actual first move?
Ours is always the same: check whether it's really down, or just down for us. Half our "outages" turned out to be one flaky region or someone's wifi. Then we check what changed in the last hour, a deploy, a DNS change, a cert.
Curious how everyone else handles it. Do you curl it, check a dashboard, tail logs, or just panic in Slack?
-
2
The interesting part isn’t the tooling—it’s the ambiguity of failure.
Most “API down” incidents aren’t binary outages, they’re partial degradations that only show up in specific regions, users, or dependencies. The real challenge is quickly separating global failure from local perception before you start debugging the wrong layer.
-
1
Exactly. A check from one location can't tell "actually down" from "looks down from here," which is why the gray failures are the worst. A 200 with half the payload missing sails past almost every uptime check out there. How do you catch those, error rate, latency, or actual response content?
-
1
That's a good question.
I don't think the interesting part is choosing between error rate, latency, or response content.
Your reply made me think about a deeper implication of how you're deciding what the product should treat as evidence of failure. I don't think I can do that reasoning justice in a thread without oversimplifying it.
If you're open to it, what's the best email to reach you on?
-
-
Comment