Uptimeify Docs

Incident abrufen

Liefert die vollständigen Details eines einzelnen Incident-Management-Incidents: den Incident-Datensatz sowie seine Alerts, Timeline-Events und Rollen-Zuweisungen.

GET /api/im/incidents/:id

Liefert die vollständigen Details eines einzelnen Incidents: den Incident-Datensatz sowie seine Alerts (eine sichere, geschwärzte Sicht, siehe unten), Timeline-Events in chronologischer Reihenfolge und Rollen-Zuweisungen.

Authentifizierung

Wie bei Incidents auflisten: jede IM-berechtigte Rolle (admin, editor, responder), oder ein organisationsweiter API-Token. Incident Management muss für die Organisation aktiviert sein.

Beispiel (cURL)

curl -X GET "$BASE_URL/api/im/incidents/42" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json"

Antwort (Response)

{
  "id": 42,
  "organizationId": 1,
  "teamId": 3,
  "title": "Database connection pool exhausted",
  "customerId": null,
  "primarySourceId": 7,
  "severity": "sev1",
  "severityManual": false,
  "status": "triggered",
  "mergedIntoId": null,
  "escalationPolicyId": 5,
  "currentTier": 1,
  "escalationEpoch": 0,
  "acknowledgedBy": null,
  "acknowledgedAt": null,
  "snoozedUntil": null,
  "autoResolve": true,
  "resolvedBy": null,
  "resolveNote": null,
  "createdBy": null,
  "sourceKind": "alert",
  "triggeredAt": "2026-07-17T09:12:00.000Z",
  "resolvedAt": null,
  "alerts": [
    {
      "id": 101,
      "organizationId": 1,
      "sourceId": 7,
      "dedupKey": "db-primary-01:pool-exhausted",
      "status": "open",
      "suppressedReason": null,
      "title": "Database connection pool exhausted",
      "severity": "sev1",
      "host": "db-primary-01",
      "mappedFields": {},
      "duplicateCount": 0,
      "firstSeenAt": "2026-07-17T09:12:00.000Z",
      "resolvedAt": null,
      "incidentId": 42
    }
  ],
  "events": [
    {
      "id": 501,
      "incidentId": 42,
      "at": "2026-07-17T09:12:00.000Z",
      "kind": "alert_received",
      "actorUserId": null,
      "actorName": null,
      "payload": {}
    },
    {
      "id": 502,
      "incidentId": 42,
      "at": "2026-07-17T09:15:00.000Z",
      "kind": "acknowledged",
      "actorUserId": "u_abc123",
      "actorName": "Jane Doe",
      "payload": {}
    }
  ],
  "assignments": [
    {
      "id": 12,
      "userId": "u_abc123",
      "userName": "Jane Doe",
      "role": "commander",
      "createdAt": "2026-07-17T09:15:00.000Z"
    }
  ]
}

events[].actorName ist der Anzeigename der Person hinter events[].actorUserId, serverseitig aufgelöst, damit Sie ihn nicht selbst nachschlagen müssen. Bei einem Systemereignis, also einem Ereignis ohne handelnde Person (ein eingehender Alert, eine feuernde Eskalationsstufe), steht dort null. Ebenfalls null steht dort, wenn sich die Person innerhalb der Organisation des Incidents nicht benennen lässt, etwa bei einem Plattform-Operator oder einem gelöschten Konto. Stellen Sie in diesem Fall eine anonyme Akteurin dar: die Kennung in actorUserId ist ein interner Bezeichner und keine Beschriftung.

alerts[].rawPayload wird von diesem Endpunkt nie zurückgegeben: das rohe Webhook-/API-Payload kann API-Keys oder andere Secrets enthalten, die der Betreiber der Source darin platziert hat. Es wird außerdem serverseitig 90 Tage nach dem Eingang durch einen Retention-Job genullt. alerts[].mappedFields ist die bereits normalisierte, sichere Sicht auf denselben Alert und übersteht die Retention.

Retention im Detail: Alert-Payloads (rawPayload) werden 90 Tage nach dem Eingang genullt; aufgelöste (resolved) Alerts werden 90 Tage nach dem Eingang gelöscht; Outbound-Delivery-Datensätze (Integrations-Weiterleitung) werden 90 Tage nach dem Versand gelöscht. Der Vorfall selbst und seine Zeitleisten-Ereignisse (events) bleiben 12 Monate nach Auslösung vollständig erhalten; danach überlebt nur noch ein Tagesaggregat (Vorfallzahlen sowie Quittier- und Auflösezeiten je Team und Schweregrad), insgesamt 24 Monate. Die täglichen Aggregate pro Source (Alert-/Dedup-/Incident-Zähler, wie im Analytics-Tab einer Source angezeigt) werden unbegrenzt aufbewahrt. Das Löschen der zugrunde liegenden Alert-Zeilen löscht diese Historie nicht mit.

Häufige Fehler

  • 401 Unauthorized wenn du nicht authentifiziert bist
  • 403 Forbidden (imAccessDenied) bei Verwendung eines kunden-gescopten Tokens, oder wenn deine Session keine IM-berechtigte Rolle hat
  • 403 Forbidden (imNotEnabled) wenn Incident Management für die Organisation nicht aktiviert ist
  • 400 Bad Request (invalidRequestBody) wenn :id keine positive Ganzzahl ist
  • 404 Not Found (imIncidentNotFound) wenn der Incident nicht existiert oder zu einer anderen Organisation gehört

Auf dieser Seite