Status pages

Public status pages fed by your monitors: components and groups, the incidents and maintenance you publish, the uptime history, the public JSON and Atom/RSS feeds, plan limits and custom domains.

A status page is a public, read-only page built from two things. The components are monitors you have chosen to show, each under a public label, with their current state and a day-by-day uptime history — that part is generated from the same results the app uses, so it is never behind. The posts are what you write: the incidents and maintenance you decide to announce, each with its own update timeline.

Page fields

Components and groups

Each entry in monitors[] becomes one component. display_name is the only name the public ever sees, so an internal api-prod-eu-1 can appear as "API" — the real monitor name, its target and its configuration never leave the auth boundary. group_name is an optional heading ("Platform", "Game services"); components sharing one sit under it and the group gets its own rolled-up state. Leave it blank and the page renders the flat list it always has.

{
  "title": "Acme status",
  "slug": "acme",
  "is_public": true,
  "window_days": 90,
  "timezone": "Europe/Berlin",
  "accent_color": "#2563eb",
  "support_url": "https://acme.example.com/support",
  "hide_from_search": false,
  "monitors": [
    { "monitor_id": "…", "display_name": "API",
      "group_name": "Platform", "sort_order": 1 },
    { "monitor_id": "…", "display_name": "Dashboard",
      "group_name": "Platform", "sort_order": 2 },
    { "monitor_id": "…", "display_name": "Matchmaking",
      "group_name": "Game services", "sort_order": 3 }
  ]
}

Publishing an incident

Nothing is announced automatically: an incident PulseTrace opens is an operational fact, and whether customers should hear about it is a decision. Publishing one creates a post — POST /api/v1/status-pages/{id}/posts with kind: "incident" — and every post carries a running timeline you add to as you learn more.

Add to the timeline with POST …/posts/{postID}/updates (status + body). Moving a post to resolved stamps resolved_at and drops it out of the active list into the record below; moving it back off resolved clears the stamp. PUT …/posts/{postID} edits the post itself and DELETE removes it — a post is your writing, so it can be corrected or withdrawn.

Maintenance

A maintenance post is the same object with kind: "maintenance". impact is forced to maintenance, and the statuses are scheduled (default) · in_progress · completed. It requires scheduled_for and scheduled_until, and the window must end after it starts. Planned work appears under its own heading before it begins, the affected components read maintenance rather than down while it runs, and the days it covered are marked as planned work in the history strip instead of counting as an outage.

The public page and its JSON

Visitors see the rendered page; the same view is available as JSON at GET /api/v1/public/status-pages/{slug} (no authentication, cached for 60 seconds) for embedding in your own site or a bot. A page that does not exist and a page with is_public off return an identical 404.

{
  "title": "Acme status",
  "slug": "acme",
  "window_days": 90,
  "timezone": "Europe/Berlin",
  "accent_color": "#2563eb",
  "support_url": "https://acme.example.com/support",
  "hide_from_search": false,
  "white_label": false,
  "generated_at": "2026-09-22T20:00:00Z",
  // operational | degraded | partial_outage |
  // major_outage | maintenance
  "overall_status": "partial_outage",
  "history_days": 14,        // how far back the posts below reach
  "monitors": [              // flat, in page order
    { "name": "API", "group": "Platform", "status": "operational",
      "uptime_percent": 99.98,
      "days_measured": 90, "days_in_window": 90,
      "history": [
        { "date": "2026-09-22", "uptime_percent": 100 }
      ] }
  ],
  "groups": [                // the same, under their headings
    { "name": "Platform", "status": "operational",
      "uptime_percent": 99.97, "monitors": [] }
  ],
  "active_incidents": [
    { "id": "…", "kind": "incident",
      "title": "Elevated error rates on the API",
      "impact": "major", "status": "identified",
      "started_at": "2026-09-22T18:04:00Z",
      "components": ["API"],
      "updates": [
        { "status": "identified", "body": "…", "created_at": "…" }
      ] }
  ],
  "maintenance": [],         // scheduled and in-progress work
  "past_posts": []           // what happened, in that window
}

A component's status is the public vocabulary — operational, degraded, down, maintenance or unknown — and never the internal monitor state. overall_status and each group's status are rolled up from the components on this page plus the maintenance currently published on it, so a page showing three of your forty monitors is never coloured by the other thirty-seven.

Uptime history, honestly

days_measured and days_in_window sit next to every uptime figure. A component created four days ago cannot claim ninety days of uptime, and the page says "4 of 90 days measured" rather than implying a record it does not have. Days with published maintenance are marked maintenance: true in the strip so planned work never reads as an outage.

Feeds

Every page publishes its posts as Atom and RSS — the one way to follow a status page that needs no address, no confirmation and nothing to unsubscribe from:

• GET /api/v1/public/status-pages/{slug}/feed.atom
• GET /api/v1/public/status-pages/{slug}/feed.rss

Both carry up to 50 posts from the last year, each entry holding the post's title, its impact or window, the components it names and its full update timeline in the page's timezone. The public page links to them in its footer and advertises them in <link rel="alternate">, so a reader app finds them from the page URL alone.

Plan limits

Components, groups, posts and feeds are on every plan, including Free.

Custom domains: current state

Related

• Trust pages publish security grades alongside uptime for one monitor or the whole organization.
• Maintenance windows keep planned work from opening incidents in the first place.
• Incidents are the internal record a published post can be linked to.