API

Status pages for API providers

Your customers are developers: they need a feed they can read in code, not only a page they can look at.

What makes an API customer different

When your product is an API, the status page is not read only by a person:

A developer wants RSS or JSON, not a newsletter
Their system wants to know the failure is on your side before it starts retrying
Their integration team wants to see history before signing an SLA

Pretty, but not automatable. A developer wants an address their code can read.

It lags during an incident, exactly when it matters, and leaves gaps in the history afterwards.

"API operational" says nothing when only the payments endpoint is down.

Every page has a machine-readable feed, so a customer's system can follow your status without a human.

Append .md, or send Accept: text/markdown, and the page comes back as text — good for agents and for documentation.

Separate components for authentication, payments and webhooks. It is clear exactly what is affected.

An SVG badge with current status or uptime, ready for your docs or GitHub page.

1
Create monitors for the main endpoints with assertions
2
Group components by what the customer actually calls
3
Turn on RSS, JSON and the badge in your documentation
4
Point to the page from your API docs and error responses
5
During an incident, publish updates — the feed reaches their systems immediately

Monitors can live in code: a YAML file and one CLI command.

Is there a machine-readable feed?

Yes: RSS, Atom and JSON, and the whole page is available as Markdown.

Can I check more than HTTP?

Yes: HTTP, TCP, DNS, ICMP, gRPC and UDP, with assertions on status, headers, body and duration.

Can I put a badge in the README?

Yes, an SVG badge showing current status or uptime.

One URL, one email address — and you will hear about the next outage from us, not from a customer.