Appearance
Incidents Beta
Public, rate-limited per IP
No auth required. Held to the shared public budget (600 requests/min per IP, 429 over). Submitting crowd reports is metered more tightly per IP and device to curb abuse. See rate limits.
The outage feed for a target: what providers have officially acknowledged, what our probes detected, and what other users are reporting right now.
- Base path:
https://ws.latency.app/v1/incidents - Auth: none (public)
List incidents
bash
# Everything currently active
curl "https://ws.latency.app/v1/incidents"The list takes no parameters. For one host use the details endpoint below: it returns a single incident object with the provider status page alongside.
One target (details)
bash
curl "https://ws.latency.app/v1/incidents/details?target=cloudflare.com"Returns everything about a single host's status in one call: the reconciled incident, the provider's own status page, the page's 30-day history, how stale that observation is, and a recent probe measurement.
json
{
"target": "cloudflare.com",
"incident": {
"domain": "cloudflare.com",
"name": "Cloudflare",
"verdict": { "label": "Operational", "tone": "ok" },
"reportCount": 0,
"reporterCount": 0,
"events": []
},
"statusPage": { "status": { "condition": "operational", "summary": "All systems operational.", "display": { "label": "Operational", "tone": "ok" } } },
"statusHistory": [ { "day": "2026-08-01", "state": "operational" } ],
"staleness": { "stale": false, "note": "updated 40s ago" },
"probe": { "avgUs": 41200, "samples": 20 }
}| Field | Meaning |
|---|---|
incident | The reconciled verdict, crowd counts, and provider status-page events. |
incident.events | The provider's status-page events for this host: ongoing first, then recently resolved. (Formerly pageIncidents.) |
statusPage | The provider's own status page, when the host is a tracked provider. |
statusHistory | Per-day page condition over the last 30 days, oldest first (no-data for days with no reading). |
staleness | How old the newest provider observation is. |
probe | Recent average measurement (µs) of our endpoint probe, with the sample count. |
Confirmation levels
Not every report is equal. An incident carries a status that says how sure we are:
| Status | Meaning |
|---|---|
unconfirmed | Some user reports, but below the threshold for a real incident. |
active | Enough independent reports for a genuine incident. |
confirmed | Corroborated by the provider's own status page or our probes. The strongest signal. |
The confirmed tier is what keeps the feed honest: a handful of reports won't turn a service red, and a provider quietly acknowledging an outage will surface even with zero user reports.
Reporting an outage
Anyone can contribute a report. Reports feed the crowd signal above.
bash
curl -X POST "https://ws.latency.app/v1/reports" \
-H 'content-type: application/json' \
-d '{ "domain": "example.com", "type": "website", "message": "timing out" }'| Field | Meaning |
|---|---|
domain | The affected domain. Required. |
type | Reason slug, e.g. website, login, app, service, other, or a slug from /reports/recommend. |
message | Optional free-text detail (most useful with type: "other"). |
To fetch the current suggested reasons for a target (used by our app's report sheet):
bash
curl "https://ws.latency.app/v1/reports/recommend?query=example.com"Crowd vs. official
The crowdVerdict in inspect reflects user reports only. The verdict stays deliberately separate from the provider's official status, so a page-confirmed outage with no reports never reads as "crowd confirmed," and vice versa.