Vorfall-Update posten

POST /api/incidents/:id/updates

Hängt ein Update an die Timeline eines Vorfalls: Der Text erscheint auf jeder Statusseite, die den Vorfall zeigt, und geht an die Abonnenten dieser Seiten. Dasselbe tun „Update posten“ im Statusseiten-Modul und das MCP-Tool post_incident_update.

Was der status des Updates ändert, hängt vom Vorfall ab (seit 28. Oktober 2026):

• Manueller Vorfall: Der Vorfall folgt dem Update. resolved behebt ihn (status und resolvedAt) und verschickt die Entwarnung; jeder andere Status auf einem behobenen Vorfall öffnet ihn wieder und benachrichtigt die Abonnenten erneut.
• Monitor-Vorfall: Nur der öffentliche Status ändert sich (publicStatus, publicResolvedAt). resolved behebt ihn auf den Statusseiten und verschickt dort die Entwarnung; jeder andere Status öffnet ihn dort wieder. Der Monitoring-Vorfall bleibt, wie er ist: Sein status und resolvedAt folgen den Checks des Monitors, nicht dem Update. Solange der Vorfall auf den Seiten noch offen ist, verschickt ein Monitor, der sich erholt, keine Entwarnung.

Entwarnung und Wiedereröffnungs-Hinweis gehen nur bei einem echten Wechsel des öffentlichen Status raus. Ein zweites resolved-Update auf einem Vorfall, der auf den Seiten schon behoben ist, wird gepostet, verschickt aber keine zweite Entwarnung.

Wiederholungen: Ein Aufruf mit demselben status und body wie ein Update, das der Vorfall schon hat, legt nichts Neues an. Er antwortet mit 200 OK, dem vorhandenen Update und deduplicated: true und verschickt nichts erneut. Einen Aufruf, dessen Antwort nicht ankam, können Sie also gefahrlos wiederholen.

Um stattdessen internen Status, Titel oder Verknüpfungen zu ändern, nutzen Sie Vorfall aktualisieren. Vorfall-Details abrufen liefert publicStatus und publicResolvedAt.

AuthentifizierungAnkerlink kopieren

Erfordert die Rolle admin oder editor im Kundenbereich des Vorfalls. Ein Vorfall ohne Kunden braucht eine organisationsweite Rolle oder einen solchen Token; für jede andere Organisation antwortet er mit 404 incidentNotFound. readonly bekommt 403 forbidden.

• Header: Authorization: Bearer <token>

PfadparameterAnkerlink kopieren

• id (Pflicht): numerische id oder publicId (UUID).

Anfrage (Request Body)Ankerlink kopieren

Beispiel (cURL)Ankerlink kopieren

curl -X POST "$BASE_URL/api/incidents/5121/updates" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "status": "identified", "body": "Ursache ist ein fehlerhafter Datenbankknoten. Wir schalten auf die Replik um." }'

Antwort (Response)Ankerlink kopieren

201 Created für ein neues Update, 200 OK für eine Wiederholung.

{
  "update": {
    "id": 8812,
    "publicId": "3f6c2a8e-6b1d-4c39-9a57-2d0e5b7c1f44",
    "status": "identified",
    "body": "Ursache ist ein fehlerhafter Datenbankknoten. Wir schalten auf die Replik um.",
    "createdAt": "2026-10-28T09:41:12.000Z"
  },
  "deduplicated": false
}

Häufige FehlerAnkerlink kopieren

• 400 Bad Request (invalidRequestBody), wenn status fehlt oder keiner der vier Werte ist oder body leer oder länger als 5.000 Zeichen ist
• 400 Bad Request (incidentNoCustomer), wenn der Vorfall weder einen Kunden noch eine Statusseite hat
• 401 Unauthorized, wenn Sie nicht authentifiziert sind
• 403 Forbidden (forbidden), wenn Rolle oder Kundenbereich das Update nicht erlauben
• 404 Not Found (incidentNotFound), wenn der Vorfall in Ihrer Organisation nicht existiert