Statuspage status values: indicator, component and incident states

If you read a vendor's /api/v2/summary.json in a bot, dashboard or alert rule, you need to know which strings can come back and how serious each one is. The words are not the same at every level: the page indicator says major, a component says major_outage, and an incident says identified. This reference lists every value I saw, with counts from a live read of 246 status pages (Atlassian Statuspage and compatible services such as incident.io) on 2026-10-13, and a small mapping you can paste into your own code.

Page indicator: status.indicator

One value for the whole page, also served alone at /api/v2/status.json. Seen across 246 pages:

Component status: components[].status

Every component (an API, a region, a feature) has its own value. The 246 pages listed 12,957 components in total:

Note that under_maintenance is not an outage. If you page someone on "anything that is not operational", planned work will wake them up.

Incident status and impact

The incidents array in summary.json holds only unresolved incidents. On 2026-10-13, 48 incidents were open across the 246 pages:

The value resolved never appears in summary.json, because resolved incidents drop out of it. You will see it in the history endpoint: GitHub's /api/v2/incidents.json returned 50 incidents on 2026-10-13, all with status resolved. The same pattern holds for maintenance: scheduled_maintenances in the summary showed scheduled (219) and in_progress (7), while GitHub's /api/v2/scheduled-maintenances.json returned 34 items, all completed. Atlassian's documentation also lists postmortem and verifying as incident states; I did not see them in this read, so treat them as possible but unobserved.

A severity mapping you can paste

Pick your own thresholds, but a sensible default is to rank the values so a rule can compare numbers instead of strings:

const COMPONENT = {
  operational: 0,
  under_maintenance: 1,   // planned, usually not an alert
  degraded_performance: 2,
  partial_outage: 3,
  major_outage: 4,
};
const INDICATOR = { none: 0, maintenance: 1, minor: 2, major: 3, critical: 4 };

const j = await (await fetch("https://www.githubstatus.com/api/v2/summary.json")).json();
const worst = Math.max(0, ...(j.components || []).map(c => COMPONENT[c.status] ?? 2));
const open = (j.incidents || []).length;   // some hosts omit empty arrays
if (worst >= 3 || INDICATOR[j.status.indicator] >= 3) alert(j.page.name);

Two details in that snippet matter. Unknown strings fall back to 2 so a new value never silently reads as healthy. And j.incidents || [] is there because incident.io's compatible endpoint leaves out empty incidents and scheduled_maintenances arrays, while Atlassian's version includes both (see the guide to status page JSON).

Check a service now

To see what a particular vendor returns, type its hostname into the free in-browser status checker. If you want the verified endpoint, platform and CORS details for 246 services in one file, that is the Status Endpoint Atlas. For incident feeds you can paste into Slack or a reader, see the list of 48 verified RSS and Atom URLs.

How I know

I fetched summary.json from each of the 246 hosts in the Atlas on 2026-10-13 (all 246 answered) and counted the strings. A snapshot is a snapshot: the percentages of pages in trouble change by the hour, but the set of value names is stable across the platform.