---
title: "Incident bestätigen / Status ändern"
description: "Bewegt einen Incident-Management-Incident zwischen den offenen Status (acknowledged, investigating, identified, monitoring). status auf acknowledged setzen, um einen Incident zu bestätigen."
---

`POST /api/im/incidents/:id/status`

Bewegt einen Incident zwischen den „offenen" Status: `triggered`, `acknowledged`, `investigating`, `identified`, `monitoring`. Jeder der vier Nicht-`triggered`-Status ist ein gültiges Ziel, unabhängig vom aktuellen Status des Incidents (nicht nur der „nächste" Status in der Reihenfolge). So **bestätigst** du auch einen Incident: `status` auf `acknowledged` setzen.

Dieser Endpunkt kann niemals `resolved` erreichen (dafür [Incident lösen](./resolve-incident) nutzen) und niemals `merged`.

## Authentifizierung

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

## Anfrage (Request Body)

| Feld | Typ | Erforderlich | Beschreibung |
|-------|------|----------|--------------|
| `status` | string | Ja | Ziel-Status. Einer von `acknowledged`, `investigating`, `identified`, `monitoring`. |

## Beispiel (cURL)

Einen Incident bestätigen:

```bash
curl -X POST "$BASE_URL/api/im/incidents/42/status" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "status": "acknowledged" }'
```

## Antwort (Response)

`200 OK`: der aktualisierte Incident-Datensatz (gleiche Form wie die `items` von [Incidents auflisten](./list-incidents)).

```json
{
  "id": 42,
  "organizationId": 1,
  "teamId": 3,
  "title": "Database connection pool exhausted",
  "customerId": null,
  "primarySourceId": 7,
  "severity": "sev1",
  "severityManual": false,
  "status": "acknowledged",
  "mergedIntoId": null,
  "escalationPolicyId": 5,
  "currentTier": null,
  "escalationEpoch": 1,
  "acknowledgedBy": "u_abc123",
  "acknowledgedAt": "2026-07-17T09:20:00.000Z",
  "snoozedUntil": null,
  "autoResolve": true,
  "resolvedBy": null,
  "resolveNote": null,
  "createdBy": null,
  "sourceKind": "alert",
  "triggeredAt": "2026-07-17T09:12:00.000Z",
  "resolvedAt": null
}
```

Der Übergang zu `acknowledged` bricht zusätzlich alle anstehenden Eskalations-Jobs des aktuellen Eskalationszyklus des Incidents ab und setzt die Ack-Timeout-Erinnerung neu scharf.

## 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, oder `status` fehlt oder keiner der vier gültigen Zielwerte ist
- `404 Not Found` (`imIncidentNotFound`) wenn der Incident nicht existiert oder zu einer anderen Organisation gehört
- `422 Unprocessable Entity` (`imIncidentInvalidStatusTransition`) wenn `status` vom aktuellen Status des Incidents aus kein zulässiges Ziel ist, z. B. ist der Incident bereits `resolved`/`merged`, oder `status` entspricht dem aktuellen Status
- `409 Conflict` (`imIncidentStatusConflict`) wenn sich der Status des Incidents zwischen Lesen und Schreiben gleichzeitig geändert hat, sicher wiederholbar