Operate an API
How a live API stays up and readable to its Customers, with a check every minute, a status page, a request log and receivers that recover on their own.
A live API is checked every minute, reports its health on the Startup's status page, and shows each Customer its own calls. A role agent runs it, and the founder hears only what needs a decision.
Who runs it
The Reliability Engineer owns uptime, incidents and failing receivers. An agent fills the seat from the start, and reads the same records the Customer sees through the builder plane.
Uptime and the status page
A Monitor checks the API every minute from several regions. A failed check opens an Incident on Status pages, which updates subscribers until it resolves.
Leaseline's page is leaseline.app/. It lists every Incident that touched an Interface, with the month so far.
What each Customer sees
| In the Portal | What it shows |
|---|---|
| Request log | Every call in the last 30 days, with its key, status and the error that names the fix |
| Usage | Calls against each Limit of the plan, with the reset time |
| Receivers | Each Watch, its recent deliveries and their status codes |
Every response also carries RateLimit-Remaining and RateLimit-Reset, so a client sees its headroom without asking. A call past the rate gets 429 rate-limited with Retry-After. Rate limits covers the mechanism.
Receivers that fail
A Watch whose deliveries all fail for three days pauses itself and notifies the Reliability Engineer. Its Events keep queuing.
Once the receiver is fixed, Watch.resume delivers the held Events, oldest first. For a longer outage, Watch.replay sends every matching Event from a chosen time again. Webhooks for your customers has the full delivery rules.
When something needs the founder
Operating an API rarely needs a decision. A raise above a plan's Limit is one: Limit.raise moves money, so it waits for the founder when an approval rule names spend. Monitoring has the logs and traces underneath.