Vorfall nachtragen
Trägt einen vergangenen, schon behobenen Vorfall mit seinen echten Zeiten auf Statusseiten nach, ohne jemanden zu benachrichtigen.
POST /api/incidents/backfill
Trägt einen Vorfall nach, der schon vorbei ist, wie „Backfill incident“ bei Atlassian Statuspage: ein Ausfall, den du ohne Statusseite behandelt hast, oder einer von vor ihrer Zeit. Du gibst Beginn und Ende an und wahlweise Updates mit eigenen Zeitpunkten. Der Vorfall entsteht behoben und erscheint auf den genannten Statusseiten:
- in der Vorfallshistorie jedes Layouts, mit seinen Updates,
- in den Verfügbarkeitsbalken der betroffenen manuellen Komponenten (Layout
statusboard), wenn seine Auswirkungpartial_outageodermajor_outageist (degradedundmaintenancezählen nicht als Ausfall). Monitor-Komponenten behalten die Balken, die ihr Monitor misst.
Er wird still erfasst: keine E-Mail, kein Webhook, keine Slack- oder Teams-Nachricht und kein Eintrag im RSS-/Atom-Feed, egal wie die Abos der Seiten eingestellt sind. Spätere Änderungen laufen über die normalen Endpunkte (zum Beispiel Vorfall-Update posten mit eigenem notifySubscribers).
Dasselbe tun „Vorfall nachtragen“ im Statusseiten-Modul und das MCP-Tool backfill_incident. Nicht idempotent: ein zweiter Aufruf trägt einen zweiten Vorfall nach.
Authentifizierung
Erfordert die Rolle admin oder editor (oder ein Organisations-API-Token). Jede Seite in statusPageIds muss zu deiner Organisation gehören (sonst 404 statusPageNotFound) und in deinem Kundenbereich liegen; ohne customerId gehört der Vorfall der Organisation, ein kundengebundener Login oder ein solches Token bekommt dann 403 forbidden. Braucht das Statusseiten-Modul (403 statusPagesModuleDisabled).
- Header:
Authorization: Bearer <token>
Request-Body
| Feld | Typ | Pflicht | Beschreibung |
|---|---|---|---|
title | string | ja | Überschrift, 1 bis 200 Zeichen. |
severity | string | ja | minor, major, critical oder maintenance. |
startedAt | string | ja | Beginn als ISO 8601, in der Vergangenheit. |
resolvedAt | string | ja | Ende als ISO 8601, in der Vergangenheit und nach startedAt. |
statusPageIds | array | ja | Statusseiten (id oder publicId), 1 bis 10. Eine Seite ohne eine der componentIds bekommt den Vorfall seitenweit. |
componentIds | array | nein | Betroffene Komponenten (id oder publicId), höchstens 100; jede muss zu einer der statusPageIds gehören. |
impact | string | nein | degraded, partial_outage, major_outage oder maintenance. Vorgabe aus severity wie bei Manuellen Vorfall anlegen. |
componentImpacts | array | nein | Auswirkung einzelner Komponenten, [{ "componentId": 8, "impact": "major_outage" }]; jede muss auch in componentIds stehen. |
customerId | integer | nein | Kunde, dem der Vorfall gehört. Dann nur Seiten ohne Kunde oder dieses Kunden. |
summary | string | nein | Bis 5.000 Zeichen. |
updates | array | nein | Bis 50 Updates { "status", "body", "createdAt" }: status ist investigating, identified, monitoring oder resolved, body 1 bis 5.000 Zeichen, createdAt ein ISO-8601-Zeitpunkt zwischen startedAt und resolvedAt. |
Zeitregeln: startedAt muss vor resolvedAt liegen und jedes Update dazwischen (400 invalidDateRange); kein Zeitpunkt darf in der Zukunft liegen (400 backfillInFuture); startedAt darf höchstens 90 Tage vor dem Anlegen der ältesten genannten Seite liegen, so weit reichen die Verfügbarkeitsbalken (400 backfillTooOld). Unbekannte Felder werden mit 400 invalidRequestBody abgewiesen.
Beispiel (cURL)
curl -X POST "$BASE_URL/api/incidents/backfill" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"title": "Zahlungen fehlgeschlagen",
"severity": "major",
"startedAt": "2026-10-20T08:10:00Z",
"resolvedAt": "2026-10-20T09:25:00Z",
"statusPageIds": [12],
"componentIds": [44],
"impact": "major_outage",
"updates": [
{ "status": "investigating", "body": "Kartenzahlungen schlagen fehl.", "createdAt": "2026-10-20T08:15:00Z" },
{ "status": "resolved", "body": "Der Anbieter hat die Störung behoben.", "createdAt": "2026-10-20T09:25:00Z" }
]
}'Antwort
201 Created
{
"incident": {
"id": 5188,
"publicId": "c1d6e0b2-7a4f-4f1e-8b33-0e9a5d2c7f18"
}
}Häufige Fehler
400 Bad Request(invalidRequestBody), wenn ein Pflichtfeld fehlt, ein Wert den falschen Typ hat,componentImpactseine Komponente außerhalb voncomponentIdsnennt oder ein unbekanntes Feld mitkommt400 Bad Request(invalidDateRange), wennstartedAtnicht vorresolvedAtliegt oder ein Update außerhalb davon400 Bad Request(backfillInFuture), wenn ein Zeitpunkt in der Zukunft liegt400 Bad Request(backfillTooOld), wennstartedAtmehr als 90 Tage vor dem Anlegen der ältesten genannten Seite liegt400 Bad Request(statusPageComponentNotOnPage,statusPageCustomerMismatch,invalidIdentifier) für Komponenten oder Seiten, die nicht passen401 Unauthorized, wenn nicht angemeldet403 Forbidden(forbidden,statusPagesModuleDisabled), wenn Rolle oder Bereich es nicht erlauben oder das Modul aus ist404 Not Found(statusPageNotFound,statusPageComponentNotFound), wenn eine Seite oder Komponente in deiner Organisation nicht existiert