About PulsAPI

Every engineering team has the same 2am story. The pager goes off, error rates are climbing, and the first twenty minutes go to answering one question: is this our code, or is it one of the forty external services we depend on?

Answering it is unreasonably slow. Each vendor publishes status somewhere different, in a different format, on a different platform, with a different idea of what “degraded” means. Some publish component-level detail; some publish a single green dot; some publish nothing at all and expect you to read a blog. There was no shared view, so every team built a private one out of browser tabs.

PulsAPI is that shared view. One dashboard, one vocabulary, one alert path. And because the same data belongs in your own systems too, there is a public API, an MCP server, and a CLI on top of it.

PulsAPI polls each vendor’s own published status source: every 60 seconds while that vendor is not fully operational or has just changed state, every 5 to 20 minutes while it is stable and unwatched. Where a vendor runs a known status platform, PulsAPI reads its API directly. Where a vendor publishes something less structured (an RSS feed, a server-rendered page, an undocumented JSON endpoint), a per-vendor fetcher handles it, and the reading carries a confidence score that says how much it should be trusted.

Component-level detail is kept where the vendor provides it, so an incident reads as “S3 in us-east-1 is degraded” rather than “AWS has issues”. Where PulsAPI has no trustworthy reading it reports UNKNOWN rather than guessing. A confidently wrong green dot is worse than an honest gap, and that principle decides most of the arguments about what to display.

Uptime and MTTR are computed from recorded observations over rolling 7, 30, and 90-day windows, not from vendor self-reporting. When PulsAPI has not watched a service long enough to fill a window, it says so instead of showing 100%.