Read the platform's daily health
The last 90 days per component, in UTC days: minutes measured, slow and failing. Public and cached for 5 minutes.
- Scopesnone
- Rate classread
/v1/status/historyThe last 90 days per component, in UTC days: minutes measured, slow and failing. Public and cached for 5 minutes.
Header Parameters
Dated API version; pinned per organisation on first use and overridable per request
Value in
- "2026-10-01"
- "2026-10-04"
ETag of a cached representation; a match returns 304
Response Body
application/json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
application/problem+json
curl -X GET "https://example.com/v1/status/history"{ "object": "status_history", "generated_at": "2019-08-24T14:15:22Z", "days": [ { "date": "2019-08-24", "components": { "property1": { "checked_minutes": 0, "degraded_minutes": 0, "outage_minutes": 0 }, "property2": { "checked_minutes": 0, "degraded_minutes": 0, "outage_minutes": 0 } } } ]}Undo an audited change POST
Puts back the change an audit entry records, by running the operation that undoes it as you: besides `audit:write`, you need the permission and scopes that operation needs, and the undo is recorded with `undo_of`. An entry's `undo` says whether it can be undone. A target changed since, or an entry already undone, answers 409; a change that cannot be undone, or older than 30 days, answers 422. So an undo never runs twice: a retry answers 409. To redo the change, undo the undo's own entry. An entry identity recorded (`source: identity`) answers 422 here: undo it with identity's `POST /v1/org/audit-events/{id}/undo`. With `FurniOps-Dry-Run` the undo is previewed.
Read the platform's current health GET
Each component's latest measured level, from the last 3 minutes. Public and cached for a minute; incidents are posted on status.furniops.com.