---
title: "Get incident"
method: GET
path: "/api/v1/incidents/{incidentID}"
tags: ["Incidents"]
---

# Get incident

`GET /api/v1/incidents/{incidentID}`

## Request

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

Returns a single incident with its evidence snapshot. Same 30-day
visibility floor as `GET /incidents` (issue #357): a resolved
incident older than 30 days 404s here as if it did not exist.

## Path parameters

- `incidentID` integer, required

## Response `200`

Incident details.

- object
  - `incident` 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.

## 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.
- `404`: Incident not found.
- `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)