Wartungsfenster planen: So bleiben Uptime-Alarme während Deploys still

Damit dich das Monitoring während eines Deploys oder einer geplanten Wartung nicht alarmiert, legst du in HyperMonitors ein Wartungsfenster an: Einstellungen → Wartung → Neues Wartungsfenster, Name vergeben, betroffene Monitore auswählen (oder auf alle anwenden), Start und Ende setzen, speichern. Solange das Fenster aktiv ist, werden die betroffenen Monitore ganz normal weiter geprüft und jedes Ergebnis landet in der Historie, aber es wird kein Vorfall eröffnet und kein Alarm verschickt. Ein Fenster lässt sich wöchentlich wiederholen, erscheint als geplante Wartung auf deiner Statusseite, und aus der Deploy-Pipeline heraus legst du es mit einem einzigen API-Aufruf an. Wartungsfenster gibt es in jedem Tarif, auch im Gratis-Tarif.

Warum nicht einfach den Monitor pausieren?

Pausieren geht, aber es kostet dich die Daten. Ein pausierter Monitor hat eine Lücke in der Historie, und zwar genau für den Zeitraum, der dich später am meisten interessiert: Hat der Rolling Deploy die Seite wirklich oben gehalten, wie lange hat die Datenbank tatsächlich gebraucht, antwortet die neue Version langsamer als die alte? Ein Wartungsfenster behält all das. Die Engine führt jede Prüfung wie gewohnt aus und speichert das Ergebnis, sie lässt nur den Teil weg, der dich aus dem Bett holt. Und anders als beim Pausieren musst du um zwei Uhr nachts nicht daran denken, den Monitor wieder einzuschalten, denn das Fenster endet von allein.

Ein einmaliges Fenster planen

Öffne die Einstellungen und wechsle auf den Reiter Wartung. Klick auf Neues Wartungsfenster und fülle aus:

• Name: wofür das Fenster da ist, bis zu 100 Zeichen. „API-Deploy 1.14“ ist besser als „Wartung“, denn der Name ist das, was die Besucher deiner Statusseite lesen.
• Umfang: Auf alle Monitore anwenden einschalten, oder ausgeschaltet lassen und die Monitore anhaken, die von der Arbeit betroffen sind. Eines von beidem muss sein, eine leere Auswahl speichert das Formular nicht.
• Start und Ende: Das Ende muss nach dem Start liegen. Die Zeiten werden in der Zeitzone deiner Organisation angezeigt, du tippst also genau das, was du meinst.
• Notiz (optional): bis zu 500 Zeichen, die auf der Statusseite neben dem Fenster stehen. „Datenbank-Migration, Logins können ein paar Minuten lang fehlschlagen“ ist die Art Satz, die Support-Tickets verhindert.

Speichern mit Fenster planen. In der Liste ist ein gerade laufendes Fenster mit Jetzt aktiv markiert, und löschen kannst du jedes jederzeit. Dauert der Deploy länger als gedacht, plane ein Anschlussfenster (oder verlängere das bestehende über die API), statt mitten in der Arbeit die Alarme losgehen zu lassen.

Lieber knapp halten

Ein Fenster ist absichtlich ein blinder Fleck, also mach es so kurz, wie die Arbeit es wirklich braucht. Eine Viertelstunde rund um einen Deploy reicht meistens. Ein großzügiges Vier-Stunden-Fenster „zur Sicherheit“ bedeutet, dass ein echter Ausfall am Ende davon unbemerkt bliebe. Und beschränke es auf die Monitore, die wirklich betroffen sind: Eine Datenbank-Migration ist kein Grund, den Monitor für die Marketing-Seite stumm zu schalten.

Wöchentlich wiederholen

Für wiederkehrende Arbeiten, etwa ein nächtliches Backup, das die Datenbank auf read-only stellt, oder das Patch-Fenster am Sonntag, schaltest du Wöchentlich wiederholen ein. Dann wählst du die Wochentage, eine Startzeit und eine Dauer in Minuten (von 1 bis 1440, also bis zu einem ganzen Tag). Start und Ende sind dann nicht mehr das Fenster selbst, sondern der Zeitraum, in dem sich das Muster wiederholt: Innerhalb davon pausieren die Alarme an den gewählten Wochentagen ab der Startzeit für die angegebene Dauer. Setz das Ende ein Jahr in die Zukunft, wenn der Slot dauerhaft ist, oder auf den letzten geplanten Lauf, wenn nicht.

Die Startzeit wird in der Zeitzone deiner Organisation interpretiert, Sommerzeit inklusive. Ein Fenster, das du mit 02:00 speicherst, greift also im Sommer wie im Winter um 02:00 Ortszeit. Das ist wichtig, wenn dein Cronjob ebenfalls nach Ortszeit läuft, und das tut er fast immer. Falls du die Zeitzone der Organisation noch nicht gesetzt hast, erledige das zuerst, in den Einstellungen.

Was deine Kunden sehen

Hast du eine öffentliche Statusseite, erscheinen Fenster, die deren Monitore abdecken, dort automatisch. Ein künftiges steht als Geplante Wartung, ein laufendes als Wartung läuft, jeweils mit Name, Zeitraum und deiner Notiz. Aus „Ist das down?“ wird so „Ah, das hatten sie angekündigt“, bevor jemand eine Mail schreibt. Statusseiten in Tarifen mit E-Mail-Abonnenten informieren diese Abonnenten auch per Mail über Wartungen, deine Kunden erfahren vom Patch-Fenster am Sonntag also genauso wie von einem Vorfall.

Weil die Checks weiterlaufen, zeigt deine Uptime-Historie, was während des Fensters wirklich passiert ist, und keine Lücke. Hat der Deploy tatsächlich eine Minute lang 503 geliefert, steht diese Minute in den Daten. Genau das brauchst du, wenn du geplante Ausfallzeiten gegen ein SLA abgleichst, denn dort lautet die Frage nie „hat es der Monitor gemerkt“, sondern „was haben wir versprochen, und haben wir angekündigte Wartung davon ausgenommen“.

Das Fenster aus der Deploy-Pipeline anlegen

Der Schritt, den die meisten Teams auslassen, ist der, der das Ganze zuverlässig macht: Die Pipeline legt das Fenster an, nicht ein Mensch. Direkt vor dem Deploy-Job öffnet eine Anfrage mit einem schreibberechtigten API-Key ein kurzes Fenster auf den Monitoren, die der Job berührt:

# HYPERMONITORS_API_KEY = write-capable key from Settings → API keys
curl -fsS https://api.hypermonitors.com/v1/maintenance-windows \
  -H "Authorization: Bearer ${HYPERMONITORS_API_KEY}" \
  -H 'content-type: application/json' \
  -d '{
    "name": "API deploy '"$GIT_SHA"'",
    "monitorIds": ["MONITOR_ID"],
    "startsAt": "'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'",
    "endsAt": "'"$(date -u -d '+15 minutes' +%Y-%m-%dT%H:%M:%SZ)"'",
    "note": "Rolling deploy, a few requests may fail briefly"
  }'

Ein leeres monitorIds-Array heißt: die ganze Organisation. Für einen wöchentlichen Slot gibst du ein recurrence-Objekt mit daysOfWeek (0 ist Sonntag, 6 Samstag), einer startTime wie 02:00 und durationMinutes mit; startsAt und endsAt begrenzen dann den Zeitraum, in dem es sich wiederholt. Derselbe Endpunkt listet mit GET die vorhandenen Fenster, und PATCH oder DELETE auf die id eines Fensters ändert oder entfernt es. Eine Pipeline, die früher fertig ist, kann das Fenster also verkürzen, statt es offen zu lassen. Die vollständige Feldliste steht in der API-Dokumentation unter Maintenance windows.