Uptimeify Docs

Wartungsfenster erstellen

Erstellt ein neues Wartungsfenster.

POST /api/maintenance-windows

Wichtig: Du musst genau eine Target-ID angeben (z. B. websiteId oder icmpMonitorId, smtpMonitorId, sshMonitorId, ftpMonitorId, imapPopMonitorId). Alle Target-IDs und customerId akzeptieren entweder die interne numerische ID oder die jeweilige Public ID als UUID.

Authentifizierung

Erfordert eine gültige Session oder einen gültigen API-Token.

  • Header: Authorization: Bearer <token>

Hinweis: Global-Supporter dürfen keine Wartungsfenster erstellen (403). Read-only Nutzer dürfen es.

Anfrage (Request Body)

{
  "websiteId": "521e3338-4597-4d1d-8eeb-dc56d271e71c",
  "name": "Server-Upgrade",
  "description": "Geplante Downtime",
  "startTime": "2026-02-25T02:00:00.000Z",
  "endTime": "2026-02-25T04:00:00.000Z",
  "isRecurring": true,
  "recurrencePattern": {
    "frequency": "weekly",
    "interval": 1,
    "daysOfWeek": [1]
  },
  "isActive": true
}

Felder

Ziel (genau eines erforderlich):

  • websiteId (number|string)
  • icmpMonitorId (number|string)
  • smtpMonitorId (number|string)
  • sshMonitorId (number|string)
  • ftpMonitorId (number|string)
  • imapPopMonitorId (number|string)
  • customerId (number|string, optional)

Identifier-Regel: Interne numerische IDs oder Public IDs als UUID werden akzeptiert.

Weitere Felder:

  • name (string, required)
  • description (string, optional)
    • Max length: 2000
    • Wenn nicht gesetzt (oder leer), wird es als null gespeichert.
  • startTime (string/date, required)
  • endTime (string/date, required)
    • Muss nach startTime liegen.
  • isRecurring (boolean, optional)
    • Default: false
  • recurrencePattern (object, optional)
    • Wird als JSON gespeichert.
    • Typische Keys: frequency, interval, daysOfWeek, dayOfMonth, endRecurrenceDate.
  • isActive (boolean, optional)
    • Default: true
  • timezone (string, optional)
    • Default: "UTC"
    • Die IANA-Zeitzone (z. B. "Europe/Berlin"), in der das Wiederholungsmuster interpretiert wird.
    • Schreibweisen unabhängig von Groß-/Kleinschreibung sowie veraltete IANA-Linknamen (z. B. "gmt", "Zulu") werden akzeptiert und unter der kanonischen Bezeichnung des Laufzeitsystems gespeichert, "utc" und "Zulu" werden beide als "UTC" gespeichert.
    • Ein reiner UTC-Offset (z. B. "+05:00") wird abgewiesen: Er enthält keine Sommerzeit-Regel und kann daher nicht leisten, was ein Zonenname leistet.

Beispiel (cURL)

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

curl -X POST "$BASE_URL/api/maintenance-windows" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"websiteId":"521e3338-4597-4d1d-8eeb-dc56d271e71c","name":"Server-Upgrade","description":"Geplante Downtime","startTime":"2026-02-25T02:00:00.000Z","endTime":"2026-02-25T04:00:00.000Z","isRecurring":true,"recurrencePattern":{"frequency":"weekly","interval":1,"daysOfWeek":[1]},"isActive":true}'

Antwort (Response)

{
  "id": 5,
  "websiteId": 101,
 "icmpMonitorId": null,
 "smtpMonitorId": null,
 "sshMonitorId": null,
 "ftpMonitorId": null,
 "imapPopMonitorId": null,
  "customerId": 12,
  "name": "Server-Upgrade",
  "description": "Geplante Downtime",
  "startTime": "2026-02-25T02:00:00.000Z",
  "endTime": "2026-02-25T04:00:00.000Z",
  "isRecurring": true,
  "recurrencePattern": {
    "frequency": "weekly",
    "interval": 1,
    "daysOfWeek": [1]
  },
  "isActive": true,
  "timezone": "UTC",
  "createdBy": "<user-id>",
  "createdAt": "2026-02-20T10:00:00.000Z",
  "updatedAt": "2026-02-20T10:00:00.000Z"
}

Häufige Fehler

  • 400 Exactly one target ID must be provided wenn du keine oder mehrere Target-IDs sendest
  • 400 Invalid Website identifier bzw. entsprechender Target-Fehler wenn ein Identifier weder Integer-ID noch UUID ist
  • 400 End time must be after start time wenn endTime <= startTime
  • 400 (Validierung) wenn timezone ein reiner UTC-Offset oder kein vom Laufzeitsystem erkannter Zonenname ist
  • 401 Unauthorized wenn du nicht angemeldet bist
  • 403 Forbidden wenn du keinen Zugriff auf das Ziel hast (oder global supporter bist)

Wiederholter Anlege-Aufruf

Eine Anfrage, die genau dasselbe Fenster verlangt, das es schon gibt, liefert DIESES Fenster zurück, statt ein zweites anzulegen, und veröffentlicht keine zweite Ankündigung auf der Statusseite. "Genau dasselbe" meint den vollständigen Anlege-Wunsch: dieselbe Kundschaft oder Organisation, derselbe Name, derselbe Start- und Endzeitpunkt, dieselbe Beschreibung, dieselbe Wiederholung, dieselbe Zeitzone, derselbe Aktiv-Schalter und dieselbe Menge an Zielen und Etiketten. Jeder Unterschied gilt als eigenes, neues Fenster, zwei gleichnamige Fenster zur selben Stunde für verschiedene Monitore bleiben also beide bestehen. Die Antwort sieht aus wie ein normales Anlegen; wer die beiden Fälle unterscheiden muss, vergleicht die zurückgegebene id.

Auf dieser Seite