---
title: "List incidents"
method: GET
path: "/api/v1/incidents"
tags: ["Incidents"]
---

# List incidents

`GET /api/v1/incidents`

## Request

- Base URL: `https://api.uptimemonitoring.com`
- URL: `https://api.uptimemonitoring.com/api/v1/incidents`
- Auth: HTTP bearer

Returns incidents for the authenticated account with optional filtering
and pagination. Ordered by start time (newest first). A resolved
incident older than 30 days is never returned here (issue #357) —
this is a visibility floor enforced at read time, independent of
how long the underlying row is physically kept (95 days, so the
uptime-report worker and a status page's 90-day daily history both
have enough lookback; see internal/retention/DECISIONS.md). An
open incident is never hidden by this floor, however old it is.

## Query parameters

- `monitor_id` integer
- `type` 'down' | 'flapping'
- `started_after` string, date-time
- `started_before` string, date-time
- `limit` integer
- `offset` integer

## Response `200`

Paginated incident list.

- object
  - `incidents` Incident[]
    - `id` integer
    - `monitor_id` integer
    - `account_id` integer
    - `type` 'down' | 'flapping'
    - `started_at` string, date-time
    - `resolved_at` string, date-time, nullable: Null if the incident is still ongoing.
    - `evidence` CheckResult[]: Snapshot of the evidence ring buffer at the time of the state transition.
      - `timestamp` string, date-time
      - `region` string
      - `status_code` integer
      - `error_class` string
      - `dns_ms` number
      - `tls_ms` number
      - `connect_ms` number
      - `ttfb_ms` number
      - `download_ms` number
      - `content_length` integer
      - `response_hash` string
      - `packet_loss_pct` number: Ping-only packet loss percentage (0-100). Omitted (not present in the object) when not measured — every non-ping check result, and a ping probe-side failure that never reached the target. A measured 0% loss is present with value 0, distinct from omitted.
    - `created_at` string, date-time
    - `maintenance` boolean: True when this incident opened while the monitor's maintenance window was active (issue #361) — or, for a down-to-flapping or flapping-to-down handoff, inherited from the incident it replaced. A monitor-wide down/flapping alert is suppressed for every recipient while this is true, and the recovery ("up") alert is suppressed too once every incident the recovery resolved carries this flag.
  - `total` integer: Total matching incidents (for pagination).
  - `limit` integer
  - `offset` integer

## Other responses

- `400`: Invalid request.
- `401`: Missing or invalid credentials.
- `403`: Account is currently suspended. On `POST /api/v1/monitors`, and on a `PUT /api/v1/monitors/{monitorID}` that changes `url` or `type` (issue #335), this can also be returned by the per-account port-scan heuristic when the triggering request crossed the port-fan threshold inside the sliding window (10 minutes by default; `SCAN_WINDOW`). A host-fan trip does NOT suspend the account — see the 429 response instead.
- `429`: Per-account dispatcher rate limit exceeded (200 requests/minute). The `Retry-After` header gives the integer seconds until at least one token has refilled. The `X-RateLimit-*` trio reflects the bucket whose rejection produced this response — usually the global 200/min cap; on `POST /api/v1/monitors` a 429 may instead reflect the per-route 20/min creation limit.

---

[API](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api.md) · [All operations](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api/llms.txt) · [OpenAPI document](https://skmtc.dev/uptimemonitoring/apis/uptimemonitoring-com-api/revisions/ddcb2a8bc70f?raw)