Status Pages
Status pages are publicly accessible dashboards summarising the state of selected monitors, organised into named groups. See Features → Status Pages for the conceptual model and visitor experience; this page is the API reference.
Endpoints
Section titled “Endpoints”| Method | Path | Description | Scope |
|---|---|---|---|
GET | /api/v1/status-pages | List status pages in the org. | status_pages |
POST | /api/v1/status-pages | Create a page. | status_pages |
GET | /api/v1/status-pages/{id} | Read one; returns the page and its full layout (groups + monitors). | status_pages |
PATCH | /api/v1/status-pages/{id} | Update metadata (name, description, custom_css, enabled). | status_pages |
DELETE | /api/v1/status-pages/{id} | Delete. | status_pages |
PUT | /api/v1/status-pages/{id}/layout | Replace the page’s group + monitor layout atomically. | status_pages |
Public read
Section titled “Public read”GET /{orgSlug}/status/{statusSlug} (no /api/v1/ prefix, no auth) renders the public HTML page. This is what visitors see. The URL is the only place a status page is reachable; there are no custom domains, and no JSON variant of the public render.
Page document
Section titled “Page document”{ "id": "01HXSP...", "org_id": "01HXORG...", "slug": "main", "name": "Example Status", "description": "Real-time status of Example, Inc.", "custom_css": "", "enabled": true, "created_at": "2026-04-01T00:00:00Z", "updated_at": "2026-04-24T17:42:03Z"}| Field | Notes |
|---|---|
slug | URL segment under /{orgSlug}/status/. Lowercase, alphanumeric, hyphens only. Immutable in practice; visitors will have bookmarked the URL. |
name | Title rendered at the top of the page and in the visitor’s browser tab. |
description | Plain text shown below the title. Markdown is NOT rendered. |
custom_css | Optional CSS injected into the page’s <style> block. Server-sanitised; see Features → Status Pages → Custom CSS for what the sanitiser strips. |
enabled | When false, the public URL returns 404. Useful for staging a new page before announcing it. |
Layout
Section titled “Layout”A page’s layout is groups (named, ordered sections) containing monitors (with per-monitor display options). There are no other component types: no service catalog widgets, no free-form text blocks, no monitor-group references.
GET /api/v1/status-pages/{id} returns the layout embedded:
{ "id": "01HXSP...", "name": "Example Status", "slug": "main", "groups": [ { "id": "01HXG1...", "name": "API", "position": 0, "default_expanded": true }, { "id": "01HXG2...", "name": "Web App", "position": 1, "default_expanded": false } ], "monitors": [ { "id": "01HXM1...", "group_id": "01HXG1...", "monitor_id": "01HXMON-API-1", "display_name": "Public API", "position": 0, "show_status": true, "show_uptime_bar": true, "uptime_periods": "30d", "show_latency": false, "show_checks": false, "show_incidents": true } ]}Replace layout
Section titled “Replace layout”PUT /api/v1/status-pages/{id}/layout
Atomically replaces the entire layout. The body declares the desired groups + monitors; the server diffs against the current state and applies the change in one transaction.
{ "groups": [ { "id": "01HXG1...", "name": "API", "position": 0, "default_expanded": true }, { "id": "01HXG2...", "name": "Web App", "position": 1, "default_expanded": true } ], "monitors": [ { "group_id": "01HXG1...", "monitor_id": "01HXMON-API-1", "display_name": "Public API", "position": 0, "show_status": true, "show_uptime_bar": true, "uptime_periods": "30d", "show_latency": false, "show_checks": false, "show_incidents": true } ]}| Field | Notes |
|---|---|
groups[].id | Optional. If you preserve the existing ID across edits, the group keeps the same handle so visitor scroll position / external links by anchor stay stable. Omit to create a new group. |
groups[].position | Order on the page, top to bottom. |
groups[].default_expanded | Whether the section is open by default. Visitors can toggle. |
monitors[].group_id | Reference to a groups[].id declared in the same request. Monitors with no group_id render in an “Other” section above the named groups. |
monitors[].monitor_id | The Monitor’s ID (from /api/v1/monitors). Monitor must be in the same org. |
monitors[].display_name | Override the monitor’s internal name. Empty = use the monitor’s own name. |
monitors[].position | Order within the group. |
monitors[].uptime_periods | What window the uptime bar covers. Common: 7d, 30d, 90d. |
monitors[].show_* | Per-monitor display flags. See the Status Pages feature page for what each renders. |
The PUT is idempotent; sending the same body twice has no effect after the first call.
Incident linkage
Section titled “Incident linkage”Incidents that should appear on a status page are linked via the Incidents API; there’s a separate IncidentStatusPage link table. An incident can be linked to multiple status pages (e.g., one incident published on both your public and partner-only pages); a status page surfaces every active incident plus the trailing 7 days of resolved incidents linked to it.
The page’s overall-status banner is computed from monitor states + the worst severity among active incidents linked to the page. See Features → Status Pages → Severity → banner mapping for the rules.
What’s not in the API
Section titled “What’s not in the API”For clarity:
- No subscribers. YipYap doesn’t currently send email/RSS/SMS to status-page visitors. There is no subscriber endpoint.
- No custom domains. Pages live at
console.yipyap.run/<org>/status/<slug>only. No CNAME or domain-mapping endpoint. - No private/auth-gated pages. Every page is fully public to anyone with the URL.
- No service-catalog components. Pages display monitors only. The service catalog is internal.
Related resources
Section titled “Related resources”- Features → Status Pages: concepts, visitor experience, custom CSS rules.
- Incidents API: incident lifecycle and status-page linking.
- Monitors API: the monitors you place on the layout.