---
title: "List incidents — open ones worst first"
method: GET
path: "/incidents"
tags: ["Incidents"]
---

# List incidents — open ones worst first

`GET /incidents`

## Request

- Base URL: `https://app.getvigilia.com/v1`
- URL: `https://app.getvigilia.com/v1/incidents`
- Auth: HTTP bearer

Open incidents come back by severity, then most recent: the order to fix them in.

## Query parameters

- `appId` string
- `status` 'open' | 'resolved' | 'ignored' | 'all'
- `severity` string
- `limit` integer

## Response `200`

Incidents.

- object
  - `incidents` Incident[], required
    - `id` string
    - `appId` string
    - `kind` 'error' | 'downtime' | 'health': error: errors from real visitors, diagnosed. downtime: the uptime checker. health: a recurring check of the app itself (secret keys in its public code, its certificate).
    - `check` 'secrets' | 'certificate' | 'domain' | 'speed' | 'null', nullable: Health incidents: which check raised it. `speed`: the app answers several times slower than its usual.
    - `details` string[]: Health incidents: the specifics, e.g. each exposed key, masked, and where it was found. Empty otherwise.
    - `endpoint` object, nullable: Downtime incidents about one of the app's extra check URLs (a page such as checkout, or an API), rather than the whole app. Null otherwise.
      - `url` string, required
      - `label` string, nullable, required: The owner's name for it, e.g. Checkout.
    - `sentry` object, nullable: The Sentry issue this incident explains, when it came through the Sentry bridge (Team). Null otherwise.
      - `url` string, required
    - `issue` object, nullable: The issue opened for this incident in GitHub Issues, Linear or Jira (Team plan), by hand or automatically. Null when there is none.
      - `tracker` 'github' | 'linear' | 'jira', required
      - `url` string, required
      - `key` string, required: #123, ENG-45, SHOP-7
    - `related` object, nullable: The same problem seen from the other side: for a request that failed with a 5xx in visitors' browsers, the server error behind it (side: server); for a server error, the failed request visitors saw (side: browser). Null when there is none.
      - `side` 'server' | 'browser', required
      - `incidentId` string, nullable, required
      - `title` string, required
      - `count` integer, required
    - `severity` 'critical' | 'high' | 'medium' | 'low'
    - `status` 'open' | 'resolved' | 'ignored'
    - `title` string
    - `summary` string: What broke, in plain language.
    - `userImpact` string: Who is affected and how.
    - `occurrences` integer, nullable
    - `sessions` integer, nullable
    - `isRegression` boolean: It was marked fixed and came back.
    - `createdAt` integer
    - `updatedAt` integer
    - `resolvedAt` integer, nullable
    - `fix` object
      - `watch` 'watching' | 'verified' | 'not_enough_traffic' | 'unverified' | 'null', nullable: `watching` until there is a verdict. `verified`: the error stayed away through enough traffic that it would very likely have shown again. `not_enough_traffic`: watched for 7 days without enough traffic to say either way. `unverified` is the same outcome as recorded before October 2026.
      - `verifiedAt` integer, nullable
      - `evidence` object, nullable: The traffic behind the verdict, or behind the wait so far. Null until the watch is first examined, 24 hours after the incident is resolved.
        - `expectedErrors` number: How many times the error would have shown up since the fix, had the fix done nothing: its rate per visit in the week before the fix, times the visits since. A fix is confirmed at 3 or more.
        - `visits` integer: Production page loads since the incident was resolved.
        - `baselineHits` integer: Sessions the error hit in the 7 days before the incident was resolved.
        - `baselineVisits` integer: Production page loads in those 7 days.
        - `measured` boolean: False when traffic for this error cannot be counted yet (errors from the app's backend). Its fix then cannot be confirmed.
        - `countedAt` integer
    - `dashboardUrl` string
    - `afterDeploy` object, nullable: The deploy this problem first appeared after, within a day. Timing, not blame.
      - `at` integer
      - `label` string, nullable
    - `providerOutage` object, nullable: A platform the app depends on (Supabase, Vercel, OpenAI…) was reporting its own incident when this began, from its public status page. There may be nothing to fix in the app. `resolvedAt` is set once the provider marks it resolved; if the problem continues after that, the cause is likely the app's.
      - `provider` string
      - `incident` string: The provider's own title for its incident.
      - `level` 'outage' | 'degraded'
      - `url` string: The provider's status page for this incident.
      - `startedAt` integer
      - `resolvedAt` integer, nullable
  - `hasMore` boolean, required

## Other responses

- `400`: A parameter has a value that isn't allowed.
- `401`: No token, or not a valid one.
- `404`: No such thing on your account.
- `429`: Too many requests for this token (`rate_limited`), or a Free account's daily requests are used up (`daily_limit`) — wait `Retry-After` seconds.

---

[API](https://skmtc.dev/getvigilia/apis/vigilia-api.md) · [All operations](https://skmtc.dev/getvigilia/apis/vigilia-api/llms.txt) · [OpenAPI document](https://skmtc.dev/getvigilia/apis/vigilia-api/revisions/43dd51b3e83a?raw)