Incident bestätigen / Status ändern
Bestätigt einen Incident-Management-Incident oder bewegt ihn zwischen den offenen Status (acknowledged, investigating, identified, monitoring).
Zwei Endpunkte ändern den Status eines offenen Incidents:
- Bestätigen ist der idempotente „Ich kümmere mich"-Aufruf. Er wirkt auf jeden offenen Incident, der noch nicht bestätigt wurde, und steht allen mit IM-Zugriff offen, denn eine Bestätigung stoppt immer nur Alarmierungen.
- Status ändern bewegt einen Incident zwischen den offenen Status, einschließlich
acknowledged. Das ist dem Team des Incidents vorbehalten.
Keiner der beiden Endpunkte kann resolved erreichen (dafür Incident lösen) oder merged (dafür Incidents zusammenführen).
Was eine Bestätigung stoppt, hängt vom aktuellen Eskalations-Tier des Incidents ab. Standardmäßig stoppt sie die ganze Eskalationskette. Ist dieser Tier so eingestellt, dass die Eskalation erst beim Lösen endet, verstummt mit der Bestätigung die aktuelle Alarmierung, weitere Tiers eskalieren aber weiter, bis der Incident gelöst ist.
Authentifizierung
Jede IM-berechtigte Rolle (admin, editor, responder) oder ein organisationsweiter API-Token, siehe Authentifizierung. Incident Management muss für die Organisation aktiviert sein.
Bestätigen
POST /api/im/incidents/:id/ack
Bestätigt einen offenen Incident, der noch keine Bestätigung trägt (acknowledgedAt ist null). Ein triggered-Incident wechselt zu acknowledged. Ein Incident, der ohne Bestätigung auf investigating, identified oder monitoring gesetzt wurde, behält seinen Status, die Bestätigung wird aber vermerkt (acknowledgedBy, acknowledgedAt) und die Eskalation stoppt genau wie bei einem triggered-Incident; status in der Antwort ist dann dieser unveränderte Status. Ein zweiter Aufruf, oder ein Aufruf auf einen resolved- oder merged-Incident, ist kein Fehler: die Antwort enthält alreadyAcknowledged: true und den aktuellen Status. Die Timeline vermerkt die Bestätigung mit source: "api" für einen API-Token und source: "ui" für eine Browser-Session.
Kein Request-Body.
Beispiel (cURL)
curl -X POST "$BASE_URL/api/im/incidents/42/ack" \
-H "Authorization: Bearer $TOKEN"Antwort (Response)
200 OK, erste Bestätigung:
{
"acknowledged": true,
"alreadyAcknowledged": false,
"status": "acknowledged",
"acknowledgedBy": "MFcTjWmYq2LpzR8vK1sXo",
"acknowledgedAt": "2026-07-17T09:20:00.000Z"
}Beide Antworten enthalten acknowledgedAt (ISO-Zeitstempel, oder null bei einem resolved/merged-Incident, der nie bestätigt wurde). Ein Incident gilt als bestätigt, wenn acknowledgedAt gesetzt ist oder status resolved bzw. merged lautet; leite das nicht aus acknowledgedBy ab, das bei einer Bestätigung per API-Token null ist.
200 OK, der Incident war bereits bestätigt:
{
"acknowledged": true,
"alreadyAcknowledged": true,
"status": "investigating",
"acknowledgedBy": "MFcTjWmYq2LpzR8vK1sXo",
"acknowledgedAt": "2026-07-17T09:20:00.000Z"
}Häufige Fehler
401 Unauthorizedwenn du nicht authentifiziert bist403 Forbidden(customerScopedTokenForbidden) bei Verwendung eines kunden-gescopten Tokens403 Forbidden(imAccessDenied) wenn die angemeldete Person keine IM-berechtigte Rolle hat403 Forbidden(imNotEnabled) wenn Incident Management für die Organisation nicht aktiviert ist400 Bad Request(invalidRequestBody) wenn:idkeine positive Ganzzahl ist404 Not Found(imIncidentNotFound) wenn der Incident nicht existiert oder zu einer anderen Organisation gehört
Status ändern
POST /api/im/incidents/:id/status
Bewegt einen Incident zwischen den offenen Status triggered, acknowledged, investigating, identified und monitoring. Jeder der vier Nicht-triggered-Status ist von jedem offenen Status aus ein gültiges Ziel, nicht nur der „nächste"; triggered selbst ist nie ein Ziel. acknowledged bestätigt den Incident und stoppt die Eskalation wie oben beschrieben. Ein direkter Wechsel von triggered zu investigating, identified oder monitoring vermerkt keine Bestätigung.
Dem Team des Incidents vorbehalten: du musst Mitglied im Team des Incidents (teamId) oder Organisations-Admin sein. Ein organisationsweiter API-Token gilt dabei als Organisations-Admin.
Anfrage (Request Body)
| Feld | Typ | Erforderlich | Beschreibung |
|---|---|---|---|
status | string | Ja | Ziel-Status. Einer von acknowledged, investigating, identified, monitoring. |
Beispiel (cURL)
curl -X POST "$BASE_URL/api/im/incidents/42/status" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{ "status": "investigating" }'Antwort (Response)
200 OK: der aktualisierte Incident-Datensatz (gleiche Form wie die items von Incidents auflisten, ohne die Ergänzungsfelder).
{
"id": 42,
"organizationId": 1,
"teamId": 3,
"title": "Database connection pool exhausted",
"customerId": null,
"primarySourceId": 7,
"severity": "sev1",
"severityManual": false,
"status": "investigating",
"mergedIntoId": null,
"escalationPolicyId": null,
"currentTier": null,
"escalationEpoch": 1,
"escalationCycle": 0,
"acknowledgedBy": "MFcTjWmYq2LpzR8vK1sXo",
"acknowledgedAt": "2026-07-17T09:20:00.000Z",
"snoozedUntil": null,
"autoResolve": true,
"resolvedBy": null,
"resolveNote": null,
"statuspageUpdate": null,
"createdBy": null,
"sourceKind": "alert",
"isTest": false,
"triggeredAt": "2026-07-17T09:12:00.000Z",
"resolvedAt": null
}Häufige Fehler
401 Unauthorizedwenn du nicht authentifiziert bist403 Forbidden(customerScopedTokenForbidden) bei Verwendung eines kunden-gescopten Tokens403 Forbidden(imAccessDenied) wenn die angemeldete Person keine IM-berechtigte Rolle hat403 Forbidden(imNotEnabled) wenn Incident Management für die Organisation nicht aktiviert ist403 Forbidden(imTeamMembershipRequired) wenn du weder Mitglied im Team des Incidents noch Organisations-Admin bist400 Bad Request(invalidRequestBody) wenn:idkeine positive Ganzzahl ist, oderstatusfehlt oder kein bekannter Statuswert ist404 Not Found(imIncidentNotFound) wenn der Incident nicht existiert oder zu einer anderen Organisation gehört422 Unprocessable Entity(imIncidentInvalidStatusTransition) wennstatustriggered,resolvedodermergedist, der Incident bereitsresolved/mergedist, oderstatusdem aktuellen Status entspricht409 Conflict(imIncidentStatusConflict) wenn sich der Status des Incidents zwischen Lesen und Schreiben gleichzeitig geändert hat, sicher wiederholbar
Incident Management
Öffentliche REST-API für Uptimeify Incident Management (IM): Alerts aus eigenen Monitoring-Systemen einspeisen und Incidents programmatisch verwalten.
Incident Management aktivieren
Schaltet Incident Management für deine Organisation ein. Idempotent: ein weiterer Aufruf bei aktivierter Organisation ändert nichts.