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.

Die Seite „Downtimes & ACKs"

Downtimes und Acknowledgements teilen sich eine Seite (Menü Downtimes & ACKs, zwei Reiter). Im Reiter Downtimes wählst du darunter den Zustand, ebenfalls als Reiter mit Anzahl: Laufend, Geplant und Abgeschlossen. Jeder zeigt seine eigene Liste mit eigenem Blättern.

Eine Zeile = ein Vorgang: ein Fenster über 40 Geräte ist eine Zeile („pve01, nas02 +38"); ein Klick klappt die einzelnen Geräte und Checks auf.

Filter (gelten für beide Reiter und stehen in der Adresse — ein Link öffnet genau diese Ansicht):

  • Suche in Grund, Gerät, Check und Tenant
  • Tenants, Geräte und Angelegt von — jeweils Mehrfachauswahl; die Geräte-Liste zeigt nur Geräte, die im Verlauf vorkommen, mit Anzahl, und sucht beim Tippen auf dem Server (auch bei tausenden Geräten)
  • Zeitraum — beliebig, letzte 24 Stunden, 7 oder 30 Tage oder Benutzerdefiniert (von–bis); gezeigt wird, was in diesen Zeitraum fällt
  • Ende (nur im Reiter „Abgeschlossen", Mehrfachauswahl) — z. B. nur vorzeitig beendete

Jeder aktive Filter steht als Chip unter der Leiste und lässt sich einzeln entfernen. Aus einem Check heraus („Alle … dieses Checks") öffnet die Seite bereits gefiltert auf dieses Gerät und diesen Check; nimmt man den Check-Chip weg, sieht man alles zu dem Gerät.

Jede Zeile zeigt Ziel, Zeitraum und Dauer, den Grund, wer sie angelegt hat — und unter „Abgeschlossen", wann und wie sie endete und von wem:

Ende Bedeutung
abgelaufen das geplante Ende wurde erreicht
vorzeitig beendet jemand hat Beenden gedrückt (Name steht dabei)
bearbeitet (ersetzt) das Fenster wurde im Dialog am Check geändert und durch ein neues ersetzt
deaktiviert eine wiederkehrende Downtime mit ungültiger Wiederholung wurde abgeschaltet
  • Bearbeiten (laufend/geplant): Grund ändern, verlängern oder früher enden lassen — gilt für den ganzen Vorgang. Der Beginn eines laufenden Fensters bleibt; bei wiederkehrenden Downtimes lässt sich nur der Grund ändern.
  • Beenden bzw. Absagen (geplant): das Fenster endet sofort.
  • Wieder aufnehmen (abgeschlossen): öffnet den Anlege-Dialog mit denselben Einstellungen — Ziel, Umfang, Grund, Wiederholung und die geplante Dauer ab jetzt. Zeit und Grund lassen sich vor dem Speichern ändern.

Im Check selbst (Check-Panel und Vollbild) zeigt der Abschnitt ACKs & Downtimes den Verlauf dieses Checks — auch Downtimes, die ihn über das Gerät oder den ganzen Tenant abgedeckt haben. Im Verlaufs-Graphen des Checks erscheinen Wartungsfenster als schraffierte Fläche und ACK-Zeiträume als Band am oberen Rand.

Konzept

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

Downtime anlegen

Downtimes & ACKs → Downtime anlegen — oder am Gerät unter Verlauf → Downtimes & ACKs (dort ist das Gerät vorgewählt). Für einzelne Checks geht es auch direkt aus Fehlerübersicht und Check-Detail („Downtime eintragen", mit Sammel-Downtime für mehrere markierte Checks).

Feld Bedeutung
Tenant Pflicht; filtert zugleich die Geräteliste darunter. Gibt es nur einen Tenant, ist er vorgewählt
Ziel Ganzer Tenant oder Geräte auswählen (eines oder mehrere)
Umfang Ganze Geräte (alle Checks) oder Einzelne Checks der gewählten Geräte
Beginn Datum + Uhrzeit, Pflicht
Ende Datum + Uhrzeit oder Schnellauswahl (siehe unten)
Kommentar optional — was wird gemacht, von wem
Wiederholen optional: Keine · Täglich · Wöchentlich · Monatlich, siehe Wiederkehrende Downtimes

Datum und Uhrzeit gelten in der Zeitzone der Instanz (Admin → Benachrichtigungen → E-Mail & Meldungen); ist keine eingestellt, in der Zeitzone des Browsers.

Ganzer Tenant

Für die Fälle, in denen wirklich alles stillsteht — Stromabschaltung, Standort-Umzug, Wartung der ganzen Umgebung — wählst du als Ziel Ganzer Tenant. Das ist ein Wartungsfenster, nicht eines pro Gerät: Du beendest es mit einem Klick, und es deckt auch Geräte ab, die während des Fensters erst angelegt werden.

Woran du es in der Liste erkennst

Solche Fenster tragen als Ziel den Tenant-Namen mit dem Zusatz „alle Geräte" statt eines Gerätenamens.

Mehrere Geräte

Unter Geräte auswählen markierst du beliebig viele Geräte des Tenants. Daraus wird ein Wartungsfenster: Es erscheint als eine Karte mit allen Gerätenamen und endet mit einem Klick auf Beenden für alle zugleich. Jedes Gerät ist dabei komplett (alle Checks) abgedeckt, oder du stellst den Umfang auf Einzelne Checks: Die Liste zeigt dann die Checks aller markierten Geräte, nach Gerät gruppiert. Darüber stehen die Checks, die es auf jedem markierten Gerät gibt (gleicher Name) — ein Klick wählt z. B. den Backup-Check auf allen Servern auf einmal. Auch das bleibt ein Wartungsfenster.

Schnellauswahl (Presets)

Statt Beginn/Ende manuell zu setzen, stehen Vorgaben zur Verfügung: 15 Min / 30 Min / 1 Std / 2 Std / 4 Std / 8 Std / 12 Std / 24 Std / Bis Tagesende / Bis morgen 08:00 / 2 Tage / 3 Tage / 1 Woche / 2 Wochen / 1 Monat. Ein Klick setzt Start = jetzt und berechnet das Ende automatisch; die gewählte Vorgabe bleibt markiert, bis du Beginn oder Ende von Hand änderst; danach lässt sich der Zeitraum bei Bedarf noch von Hand anpassen. Dieselbe Liste steht im Downtime-Dialog am Gerät und beim Acknowledge unter „Befristet bis".

Wiederkehrende Downtimes

Für regelmäßige Wartungsfenster wählst du unter Wiederholen:

Option Wirkung
Täglich jeden Tag zur Uhrzeit von Beginn bis Ende
Wöchentlich an den gewählten Wochentagen (ohne Auswahl: am Wochentag des Beginns)
Monatlich am Kalendertag des Beginns (ein Fenster am 29.–31. rutscht nicht auf den 28.; Monate ohne diesen Tag entfallen)
Endet Nie oder An einem Datum — das Ende gilt bis zum Ende des gewählten Tages

Beginn und Ende legen das erste Fenster und damit die Dauer jedes Vorkommens fest. Unter der Auswahl steht eine Zusammenfassung, z. B. „Wöchentlich (Mo, Mi) 02:00–04:00 (Europe/Rome)".

Wochentag, Monatstag und Uhrzeit gelten in der Zeitzone der Instanz — „jeden Montag 00:30" bleibt Montag 00:30 Ortszeit, auch über die Sommerzeit-Umstellung hinweg. Ohne eingestellte Instanz-Zeitzone gilt UTC. (Bis v1.903.0 wurde immer in UTC gerechnet.)

Abgelehnt werden beim Speichern: ein Ende der Wiederholung vor dem ersten Fenster, Regeln, die nie zutreffen (z. B. am 30. Februar), und zu dichte Regeln (sekündlich; bei stündlicher oder minütlicher Wiederholung über die API nur Uhrzeit-Angaben, keine Tage). Bestehende Regeln, die so nicht mehr erlaubt sind, schaltet Vesana einmalig ab; sie stehen dann im Verlauf als „deaktiviert" und im Diagnose-Log.

Eine laufende wiederkehrende Downtime lässt sich nur im Grund bearbeiten — für andere Zeiten beenden und neu anlegen.

Downtime-Lebenszyklus

stateDiagram-v2
    [*] --> Geplant: angelegt, Beginn in Zukunft
    Geplant --> Laufend: Beginn erreicht
    Laufend --> Abgelaufen: Ende erreicht
    Laufend --> Beendet: „Beenden"
    Geplant --> Beendet: „Absagen"
    Laufend --> Ersetzt: am Check bearbeitet
    Abgelaufen --> [*]
    Beendet --> [*]
    Ersetzt --> [*]

Ein Hintergrund-Job beendet abgelaufene Fenster und schaltet die Wartung an den Checks ab. Beendete Downtimes bleiben als Verlauf erhalten.

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

Die Unterdrückung wirkt live — schon der Alarm-Pfad selbst prüft die aktive Downtime, nicht erst ein separater Hintergrund-Job, der das Wartungs-Flag mit ein paar Sekunden Verzögerung nachzieht. Es gibt also keine kurze Lücke direkt nach Downtime-Beginn, in der trotzdem noch eine Mail rausgehen könnte.

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

SLA-Berechnung

SLA-Berechnungen nehmen Wartungsfenster minutengenau aus der Rechnung — die Zeit zählt weder als verfügbar noch als Ausfall. Das gilt für Downtimes auf einzelnen Checks, Geräten und ganzen Tenants gleichermaßen.

Details: SLA-Reports.

Mehrere Geräte per API

Dasselbe wie im Dialog: host_ids statt host_id legt ein Wartungsfenster für alle genannten Geräte an (alle Geräte müssen zum selben Tenant gehören).

curl -X POST -H "Authorization: Bearer <JWT>" -H "Content-Type: application/json" \
  -d '{
    "host_ids": ["<uuid-1>", "<uuid-2>"],
    "start_at": "2026-04-25T22:00:00Z",
    "end_at":   "2026-04-25T22:30:00Z",
    "comment":  "Reboot nach Kernel-Update"
  }' \
  https://deine-domain.tld/api/v1/downtimes/

Die Antwort trägt batch_id; DELETE /api/v1/downtimes/batch/<batch_id> beendet das Fenster für alle Geräte zugleich.

Vorzeitig beenden

Laufende Downtime → Beenden. Ab sofort feuern Alerts wieder; im Verlauf steht „vorzeitig beendet" mit Zeitpunkt und Namen.

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

Audit

Im Audit-Log: downtime_create (bzw. bulk_downtime_create), downtime_update (mit Vorher/Nachher) und downtime_delete (mit Grund ended oder replaced).

Anschluss