Uptimeify Docs

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 Auswirkung partial_outage oder major_outage ist (degraded und maintenance zä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

FeldTypPflichtBeschreibung
titlestringjaÜberschrift, 1 bis 200 Zeichen.
severitystringjaminor, major, critical oder maintenance.
startedAtstringjaBeginn als ISO 8601, in der Vergangenheit.
resolvedAtstringjaEnde als ISO 8601, in der Vergangenheit und nach startedAt.
statusPageIdsarrayjaStatusseiten (id oder publicId), 1 bis 10. Eine Seite ohne eine der componentIds bekommt den Vorfall seitenweit.
componentIdsarrayneinBetroffene Komponenten (id oder publicId), höchstens 100; jede muss zu einer der statusPageIds gehören.
impactstringneindegraded, partial_outage, major_outage oder maintenance. Vorgabe aus severity wie bei Manuellen Vorfall anlegen.
componentImpactsarrayneinAuswirkung einzelner Komponenten, [{ "componentId": 8, "impact": "major_outage" }]; jede muss auch in componentIds stehen.
customerIdintegerneinKunde, dem der Vorfall gehört. Dann nur Seiten ohne Kunde oder dieses Kunden.
summarystringneinBis 5.000 Zeichen.
updatesarrayneinBis 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, componentImpacts eine Komponente außerhalb von componentIds nennt oder ein unbekanntes Feld mitkommt
  • 400 Bad Request (invalidDateRange), wenn startedAt nicht vor resolvedAt liegt oder ein Update außerhalb davon
  • 400 Bad Request (backfillInFuture), wenn ein Zeitpunkt in der Zukunft liegt
  • 400 Bad Request (backfillTooOld), wenn startedAt mehr als 90 Tage vor dem Anlegen der ältesten genannten Seite liegt
  • 400 Bad Request (statusPageComponentNotOnPage, statusPageCustomerMismatch, invalidIdentifier) für Komponenten oder Seiten, die nicht passen
  • 401 Unauthorized, wenn nicht angemeldet
  • 403 Forbidden (forbidden, statusPagesModuleDisabled), wenn Rolle oder Bereich es nicht erlauben oder das Modul aus ist
  • 404 Not Found (statusPageNotFound, statusPageComponentNotFound), wenn eine Seite oder Komponente in deiner Organisation nicht existiert

Auf dieser Seite