How to read a status page's JSON API (and what 246 of them look like)

Most vendor status pages are built on Atlassian Statuspage or a compatible service, and they expose the same read-only JSON API under /api/v2/. On 2026-10-09 I fetched /api/v2/summary.json from 686 candidate hostnames. 240 qualified, and six more hosts I probed the same way afterwards brought the Status Endpoint Atlas to 246. A row needs HTTP 200, a valid body with a status.indicator, and at least one component. Here is what that sample says about the format, and what to watch for when you build on it.

The four endpoints worth knowing

• summary.json: the overall indicator, every component and, when there are any, open incidents and scheduled maintenance, in one request. This is the one to poll. Atlassian's version always includes the incidents and scheduled_maintenances arrays; incident.io's leaves them out when empty (see below).
• status.json: only the overall indicator (none, minor, major or critical). It answered on 246 of 246 rows.
• components.json: the component list. It answered on 246 of 246 rows.
• history.rss and history.atom: incident history feeds. Both worked on 235 rows; 11 services (Airtable, AppsFlyer, Couchbase Capella, Ecwid, GoDaddy, Gusto, Hevo, Hostinger, Oracle NetSuite, Shopify, Tabnine) do not serve either feed (10 return 404, Gusto redirects away), so you cannot rely on a feed for every vendor.

What the sample shows

• 203 rows came back with Atlassian's x-statuspage-version header and 42 through incident.io's compatibility route. The two are close but not identical: when I checked live, 38 of the 42 incident.io rows had no incidents key and 35 had no scheduled_maintenances key, apparently because they are left out when empty. One parser can serve both only if it treats a missing key as an empty list, for example j.incidents || []. Do not assume the keys exist.
• Component counts vary a lot. The median is 18; the largest are Duo (847), Snowflake (728), Elastic Cloud (638). A page with 800 components is not something to render as a flat list.
• 246 of 246 responses carried Access-Control-Allow-Origin: * on a plain GET with an Origin header, so a browser can usually read them directly. I did not test preflighted requests.
• 21 of 246 pages were not at none when fetched, so even at one moment in time a handful of vendors usually have something open. Treat the indicator as a snapshot.

Polling safely

Cache responses and poll at 60 seconds or slower. Handle a non-200 or a body that fails to parse as "unknown", never as "operational": a status page that is down is not a green one. Check status.indicator against the four known values and ignore anything else.

Where the numbers come from

Every figure above was computed by script from the Atlas data files, which were built from live fetches on 2026-10-09. A second check re-fetched 41 of the first 240 rows with curl (30 random, the 10 rows without feeds and the one unidentified platform) and found no differences in component counts, groups or feed availability. The full file, with the status page URL, summary.json URL, platform, groups, feeds and fetch date for every row, is the paid Status Endpoint Atlas; there is a free 25-row sample on the product page.