Zum Inhalt

Downtimes

Eine Downtime ist ein Zeitraum, in dem ein Host oder Service erwartet ausfallen darf — Wartung, Reboot, Migration. Während einer aktiven Downtime werden Alerts nicht versandt.

Konzept

[Live-Status]                    Service: CRITICAL
[während Downtime aktiv]         Status sichtbar, kein Alert
[nach Downtime]                  Wenn weiterhin CRIT → Alert (oder Recovery)

Downtime anlegen

/downtimes → Neu oder direkt aus dem Host-Kontextmenü.

Feld Bedeutung
Scope Host, Service, oder mehrere via Tag-Filter
Beginn Datum + Uhrzeit (lokale Zeit, nicht UTC!)
Ende Datum + Uhrzeit oder „Dauer"
Kommentar Pflicht — was wird gemacht, von wem
Recurring? Optional, dann RRULE

datetime-local sind lokale Zeit

Das Frontend benutzt für Datums-Eingabe datetime-local-HTML-Inputs in lokaler Zeit. Wenn du via API arbeitest, schicke ISO-Zeiten in UTC mit Z-Suffix — das Backend konvertiert.

Recurring (RRULE)

Für regelmäßige Wartungsfenster:

FREQ=WEEKLY;BYDAY=SU;BYHOUR=2;BYMINUTE=0
→ jeden Sonntag 02:00
Feld Beispiel
Frequenz DAILY, WEEKLY, MONTHLY
Wochentage MO, TU, …, SU
Tag im Monat 1, 15, -1 (=letzter Tag)
Ablauf bis Datum X oder N Wiederholungen
Dauer pro Vorkommnis z. B. 4h

UI generiert daraus den RRULE-String, im Backend wird der Standard iCalendar RRULE genutzt.

Vorschau im Modal: zeigt die nächsten 5 berechneten Vorkommen.

Mobile-Schnellanlage

In der Mobile-App: Host-Detail → Schnell-Downtime → 30 Min / 1 h / 4 h / 24 h mit Kommentar in einem Schritt.

Sinnvoll wenn jemand on-call ist und kurz weg muss („Kaffeeholen, das Backup darf 30 min schweigen").

Downtime-Lebenszyklus

stateDiagram-v2
    [*] --> Scheduled: angelegt, Beginn in Zukunft
    Scheduled --> Active: Beginn-Zeit erreicht
    Active --> Expired: Ende-Zeit erreicht
    Active --> Cancelled: vorzeitig beendet
    Scheduled --> Cancelled: vor Beginn gelöscht
    Expired --> [*]
    Cancelled --> [*]

Der downtime_expiry_watcher (Background-Job) räumt abgelaufene Downtimes auf — verschiebt sie aus active in expired.

Auswirkungen

Während aktiver Downtime:

  • Check läuft normal weiter
  • Status sichtbar im UI mit Wartungs-Badge
  • Alert-Rules ignorieren den Service
  • Mobile-Push nicht
  • E-Mail-Notifications nicht
  • Webhooks nicht

Im Audit-Log: An- und Auflösen einer Downtime ist eingetragen, mit Author und Kommentar.

SLA-Berechnung

SLA-Reports schließen Downtime-Zeiträume per Default aus — die Verfügbarkeit zählt während Wartungen als „nicht relevant", nicht als „Ausfall".

Konfigurierbar pro Report: „Downtimes als Ausfall werten" für strenge Compliance-Sicht.

Details: SLA-Reports.

Bulk-Downtime

Tag-basiert: alle Hosts mit production für 30 min in Wartung.

curl -X POST -H "Authorization: Bearer <JWT>" \
  -d '{
    "scope": { "tag": "production" },
    "starts_at": "2026-04-25T22:00:00Z",
    "ends_at":   "2026-04-25T22:30:00Z",
    "comment":   "Reboot nach Kernel-Update"
  }' \
  https://deine-domain.tld/api/v1/downtimes/

Das Backend resolved den Tag-Filter zu konkreten Hosts und legt eine Downtime pro Host an.

Vorzeitig beenden

Aktive Downtime → Beenden. Ende-Zeitpunkt wird auf Now gesetzt, ab sofort feuern Alerts wieder.

Sinnvoll wenn Wartung früher fertig ist — du willst dann sofort wissen, ob noch was kaputt ist.

Audit

Jede Downtime-Aktion (anlegen, ändern, beenden) ist im Audit-Log mit action = downtime.create / update / cancel und Diff der Felder.

Anschluss