---
title: "Vorfall nachtragen"
description: "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](/de/api/monitoring/post-incident-update) 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](/de/api/monitoring/create-manual-incident). |
| `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)

```bash
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`

```json
{
  "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