Status Page
A status page provides API consumers with real-time information regarding the up-time and availability of each API being made available. Status pages often provide current as well as historical information regarding stability or outages, helping build trust with consumers over time regarding the health of an API platform.
Also known as: Health Page, Uptime, Incidents
Example
Standards
- IETF RFC 4287 — The Atom Syndication Format
- IETF RFC 5005 — Feed Paging and Archiving (Atom)
- IETF RFC 3339 — Date and Time on the Internet — Timestamps
- Community spec RSS 2.0 Specification
- Community spec JSON Feed v1.1
- Vendor Atlassian Statuspage API
- Open source Cachet (open-source status page)
- IETF (expired draft) Health Check Response Format for HTTP APIs (draft-inadarei-api-health-check)
HTTP Headers
| Header | Direction | Spec | Description |
|---|---|---|---|
Cache-Control |
response | RFC 9111 | Status payloads are typically short-cached so dashboards refresh quickly. |
Last-Modified |
response | RFC 9110 §8.8.2 | Indicates the last time the status payload changed. |
Well-Known Paths
/.well-known/health— De facto — Common convention for service health endpoints (no IANA registration).
Media Types
application/atom+xml— RFC 4287 — Common feed format for incident histories.application/rss+xml— RSS 2.0 — Widely used for incident feeds.application/feed+json— JSON Feed v1.1application/health+json— draft-inadarei-api-health-check — Health-check response document for HTTP APIs.
OpenAPI Expression
-
servers(OpenAPI 3.x) — A status API can be documented as its own OpenAPI document alongside the product API. -
paths./health(De facto) — Conventional path for a machine-readable health endpoint.
Governance Rules
naftiko-status-page(Naftiko Sandbox (status-page/*.yml)) — Rules that verify each API references a status page and exposes machine-readable feeds.
Risk & Compliance
Compliance:
- SOC 2 A1.2 — environmental and operational monitoring communicated to users
- ISO/IEC 27001 A.17 — information-security aspects of business continuity
Security: Status pages should not leak internal infrastructure detail (host names, internal component IDs, stack traces) in incident write-ups. They are also a high-trust channel; compromise of the status page can be used for social engineering, so apply the same auth, change-management, and integrity controls as the primary API.
Tools
- Atlassian Statuspage — Hosted
- Cachet — Self-hosted (BSD-3-Clause)
- Instatus — Hosted
- Better Stack (Better Uptime) — Hosted
- Upptime — Self-hosted (GitHub Actions) (MIT)
- Gatus — Self-hosted (Apache-2.0)
Suggested Metrics
uptime_percentage— Rolling availability across a defined window (e.g. 30/90/365 days).mttr_minutes— Mean time to recover from declared incidents.mttd_minutes— Mean time to detect / declare an incident from first impact.incident_count— Declared incidents per period, segmented by severity.component_availability— Per-component uptime; aligns with Statuspage component model.
Example Implementations
- GitHub — githubstatus.com with component-level status and RSS/Atom incident feeds.
- Stripe — status.stripe.com with per-product components and historical uptime.
- Twilio — status.twilio.com powered by Statuspage with regional component breakdown.
- Cloudflare — www.cloudflarestatus.com with PoP-level component reporting.
Related Properties
Tags
- Status
- Health
- Reliability