Skip to content

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.

MethodPathDescriptionScope
GET/api/v1/status-pagesList status pages in the org.status_pages
POST/api/v1/status-pagesCreate 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}/layoutReplace the page’s group + monitor layout atomically.status_pages

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.

{
"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"
}
FieldNotes
slugURL segment under /{orgSlug}/status/. Lowercase, alphanumeric, hyphens only. Immutable in practice; visitors will have bookmarked the URL.
nameTitle rendered at the top of the page and in the visitor’s browser tab.
descriptionPlain text shown below the title. Markdown is NOT rendered.
custom_cssOptional CSS injected into the page’s <style> block. Server-sanitised; see Features → Status Pages → Custom CSS for what the sanitiser strips.
enabledWhen false, the public URL returns 404. Useful for staging a new page before announcing it.

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
}
]
}

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
}
]
}
FieldNotes
groups[].idOptional. 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[].positionOrder on the page, top to bottom.
groups[].default_expandedWhether the section is open by default. Visitors can toggle.
monitors[].group_idReference 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_idThe Monitor’s ID (from /api/v1/monitors). Monitor must be in the same org.
monitors[].display_nameOverride the monitor’s internal name. Empty = use the monitor’s own name.
monitors[].positionOrder within the group.
monitors[].uptime_periodsWhat 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.

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.

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.