Read your incidents and scheduled maintenances as JSON, straight from your status page.
Every status page serves two public JSON endpoints alongside the page itself. They need no API key, they return the same history your visitors see, and they use the response shapes statuspage.io publishes, so integrations written against a statuspage.io page keep working once you switch.
Reach for them when:
| Endpoint | Returns |
|---|---|
GET /api/v1/incidents.json | Incidents and outages |
GET /api/v1/scheduled_maintenances.json | Maintenance windows |
Both live on your status page domain, so a page on status.acme.com serves https://status.acme.com/api/v1/incidents.json. The Hyperping-hosted slug works the same way.
curl https://meta.hyperping.app/api/v1/incidents.json[
{
"id": "6kddbqdycckq",
"start_date": "2026-07-06T23:18:06.000Z",
"end_date": "2026-07-07T00:38:17.000Z",
"name": "EU voice call phone number unavailable",
"title": { "en": "EU voice call phone number unavailable" },
"type": "incident",
"status": "resolved",
"link": "https://meta.hyperping.app/history/inci_MiabOZOm5ObN2h"
}
]| Parameter | Type | Default | Description |
|---|---|---|---|
status | string | all | Filter by incident status |
type | string | all | Filter by incident type |
limit | integer | 50 | Results per page, 50 maximum |
page | integer | 1 | Page number |
| Value | Meaning |
|---|---|
ongoing | No resolved update yet |
resolved | Closed with a resolved update |
investigating | Currently being investigated |
identified | Cause has been identified |
update | Progress update posted |
monitoring | Fix deployed, watching for stability |
outage for service outages, incident for everything else.
/api/v1/incidents.json?status=ongoing returns only what is unresolved right now/api/v1/incidents.json?type=outage&status=resolved returns resolved outages/api/v1/incidents.json?limit=20&page=2 pages through the historycurl "https://meta.hyperping.app/api/v1/scheduled_maintenances.json?status=upcoming"[
{
"id": "t4btxayrds4g",
"start_date": "2026-08-15T14:30:00.000Z",
"end_date": "2026-08-15T18:30:00.000Z",
"name": "API infrastructure upgrade",
"title": { "en": "API infrastructure upgrade" },
"status": "upcoming",
"link": "https://meta.hyperping.app/history/mw_6ckvtMuyDhMfto"
}
]Same limit and page as incidents, plus a status filter with its own values:
| Value | Meaning |
|---|---|
upcoming | Scheduled for the future |
inprogress | Running right now |
completed | Finished |
all | Every maintenance window |
With no status parameter you get upcoming and ongoing windows only, which is what a "what is coming up" widget usually wants.
| Field | Type | Description |
|---|---|---|
id | string | Stable identifier for the entry |
start_date | string | ISO 8601 start of the incident or window |
end_date | string | ISO 8601 end, once there is one |
name | string | Title in the page's default language |
title | object | Title keyed by language code, for multilingual pages |
type | string | Incidents only: outage or incident |
status | string | Current status, from the values above |
link | string | Permalink to the entry on your status page |
Every status page hosts its own copy of this reference at /docs, filled in with your domain. Send integrators to https://status.acme.com/docs and they get the endpoints, parameters, and example responses without needing a Hyperping account.
Both endpoints are open to anonymous requests on public pages and send Access-Control-Allow-Origin: *, so a browser front-end can call them directly without a proxy.
On a protected page they answer 401 unless the request carries a valid session, the same rule the feeds follow. Publishing an incident update clears the cache immediately, so a poller sees a new incident on its next request.
The status page is password or SSO protected. These endpoints only serve anonymous requests on public pages.
limit is capped at 50 per request. Page through with page=2, page=3, and so on rather than raising the limit.
Without a status parameter the endpoint returns upcoming and ongoing windows only. Add ?status=all to include completed ones.
Use the status.json endpoint. It returns a single indicator and an uptime percentage, which is what a badge or a health check wants.