---
title: "Wartung planen"
description: "Plant eine Wartung für Status-Seiten und Komponenten, mit Ankündigung, Erinnerung, Beginn- und Ende-Nachricht."
---

`POST /api/status-pages/maintenances`

`state` kommt aus der Uhr und wird nie gespeichert: `scheduled` vor `scheduledFor`, `in_progress` bis `scheduledUntil`, danach `completed`; `cancelled`, sobald abgesagt. Die Wartung beginnt und endet von selbst, dafür ist kein Aufruf nötig. Solange sie `in_progress` ist, zeigen ihre Komponenten auf der öffentlichen Seite `maintenance` (ein schlimmerer Zustand wie ein Ausfall bleibt); eine Wartung ohne Komponenten zeigt die ganze Seite in Wartung.

Abonnenten der Status-Seite (oder einer betroffenen Komponente) bekommen über ihren Kanal (E-Mail, Webhook, Slack, Teams) die Ereignisse `maintenance_scheduled` (beim Speichern und erneut, wenn ein bevorstehender Beginn verschoben wird), `maintenance_reminder`, `maintenance_started`, `maintenance_completed`, `maintenance_update` und `maintenance_cancelled`. Die Schalter unten bestimmen, welche davon verschickt werden; jedes Ereignis steht außerdem im RSS- und Atom-Feed der Seite. Der Versand beachtet die Abo-Verzögerung der Seite und wird zur Sendezeit entschieden: eine verschobene oder abgesagte Wartung verschickt ihre überholten Nachrichten nicht.

Eine Wartung hier informiert die Besucher deiner Status-Seiten. Sie pausiert keine Monitor-Alarme: dafür legst du im Monitoring ein [Wartungsfenster](/de/api/maintenance-windows) an, das auch auf Seiten mit diesen Monitoren erscheint.

## Zugriff

Organisations-`admin` und `editor`. Ein kundengebundener Nutzer oder API-Token erreicht nur Wartungen, deren Status-Seiten alle zu einem Kunden in seinem Bereich gehören; eine Seite ohne Kunde (`customerId: null`) ist Org-weiten Rollen vorbehalten. Eine Wartung einer anderen Organisation antwortet `404` (`statusPageMaintenanceNotFound`). IDs im Pfad nehmen die numerische ID oder die `publicId`. Die Änderung steht im Audit-Protokoll der Organisation.

## Request-Body

| Feld | Typ | Pflicht | Standard | Beschreibung |
|------|-----|---------|----------|--------------|
| `title` | string | Ja | - | Steht auf der Seite und in jeder Nachricht (1-200 Zeichen). |
| `description` | string\|null | Nein | `null` | Was passiert und was Besucher merken (max. 5000 Zeichen). |
| `scheduledFor` | string | Ja | - | Beginn, ISO 8601 mit Versatz (`Z` oder `+01:00`); gespeichert und zurückgegeben in UTC. |
| `scheduledUntil` | string | Ja | - | Ende, nach `scheduledFor`. |
| `statusPageIds` | array | Ja | - | Status-Seiten (ID oder `publicId`, 1-10), die die Wartung zeigen. |
| `componentIds` | array | Nein | `[]` | Betroffene Komponenten (ID oder `publicId`, bis 100) jeder Quelle: manuell, Monitor oder Drittanbieter. Jede muss zu einer der `statusPageIds` gehören. Eine Seite ohne genannte Komponente zeigt die Wartung seitenweit. |
| `notifyOnSchedule` | boolean | Nein | `true` | Beim Speichern an Abonnenten ankündigen, und erneut, wenn ein bevorstehender Beginn verschoben wird. |
| `reminderMinutesBefore` | number\|null | Nein | `null` | Abonnenten so viele Minuten (5-10080) vor dem Beginn erinnern; `null` schickt keine Erinnerung. |
| `notifyOnStart` | boolean | Nein | `false` | Abonnenten bei Beginn benachrichtigen. |
| `notifyOnComplete` | boolean | Nein | `true` | Abonnenten bei Ende benachrichtigen. |

Unbekannte Felder werden abgewiesen. Eine Wartung, die ganz in der Vergangenheit liegt, wird ohne Ankündigung gespeichert.

## Beispiel (cURL)

```bash
BASE_URL="https://uptimeify.io"
TOKEN="<dein-api-token>"

curl -X POST "$BASE_URL/api/status-pages/maintenances" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title": "Database upgrade", "scheduledFor": "2026-11-03T23:00:00+01:00", "scheduledUntil": "2026-11-04T00:00:00+01:00", "statusPageIds": [1], "componentIds": [7], "reminderMinutesBefore": 60}'
```

## Antwort

`201 Created` mit der Wartung:

```json
{
  "id": 12,
  "publicId": "3f1c2a9e-5b7d-4c8e-9a1f-2b3c4d5e6f70",
  "organizationId": 4,
  "title": "Database upgrade",
  "description": "Checkout may be slow for a few minutes.",
  "scheduledFor": "2026-11-03T22:00:00.000Z",
  "scheduledUntil": "2026-11-03T23:00:00.000Z",
  "state": "scheduled",
  "notifyOnSchedule": true,
  "reminderMinutesBefore": 60,
  "notifyOnStart": false,
  "notifyOnComplete": true,
  "cancelledAt": null,
  "statusPageIds": [1],
  "componentIds": [7],
  "links": [
    {
      "statusPageId": 1,
      "statusPagePublicId": "0b6f3c1e-8d2a-4f5b-9c7e-1a2b3c4d5e6f",
      "statusPageName": "Acme Status",
      "componentId": 7,
      "componentPublicId": "5a1b2c3d-4e5f-4a6b-8c7d-9e0f1a2b3c4d",
      "componentName": "Checkout"
    }
  ],
  "updates": [],
  "createdAt": "2026-10-28T09:00:00.000Z",
  "updatedAt": "2026-10-28T09:00:00.000Z"
}
```

## Felder

- `statusPageIds` und `componentIds` geben die Anfrage wieder; `links` nennt jede Seite und Komponente (`componentId: null` = die ganze Seite).
- `updates` sind die öffentlichen Updates, älteste zuerst (siehe [Wartungs-Update veröffentlichen](/de/api/status-pages/post-status-page-maintenance-update)).

## Häufige Fehler

- `400 Bad Request` (`invalidRequestBody`), wenn ein Feld fehlt, den falschen Typ hat oder unbekannt ist; `data.issues` nennt das Feld
- `400 Bad Request` (`invalidDateRange`), wenn `scheduledUntil` nicht nach `scheduledFor` liegt
- `400 Bad Request` (`invalidIdentifier`), wenn eine ID weder Zahl noch UUID ist
- `400 Bad Request` (`statusPageComponentNotOnPage`), wenn eine Komponente zu keiner der `statusPageIds` gehört
- `401 Unauthorized`, wenn du nicht angemeldet bist
- `403 Forbidden` (`forbidden`), wenn deine Rolle das nicht darf, oder für einen kundengebundenen Aufrufer auf einer Seite ohne Kunde oder eines anderen Kunden
- `403 Forbidden` (`statusPagesModuleDisabled`), wenn das Statusseiten-Modul nicht aktiviert ist
- `404 Not Found` (`statusPageNotFound`), wenn eine Status-Seite nicht existiert oder zu einer anderen Organisation gehört
- `404 Not Found` (`statusPageComponentNotFound`), wenn es eine Komponente nicht gibt