# Wartungsfenster richtig setzen: Geplante Downtime ohne Fehlalarm-Lawine > So pausierst du mit einem Wartungsfenster die Alarmierung bei geplanter Wartung und zeigst sie in der Status-Historie sauber als Wartung an. Source: https://uptimeify.io/de/blog/wartungsfenster-monitoring Ein Wartungsfenster ist ein geplanter Zeitraum, in dem dein Monitoring die Alarmierung für ausgewählte Monitore bewusst pausiert, damit ein Deployment, ein Server-Neustart oder eine Migration keine Alarm-Lawine auslöst und in der Status-Historie sauber als Wartung statt als Ausfall erscheint. Der Unterschied zu einer plumpen Stummschaltung: Der Rest deines Portfolios bleibt scharf, die geplante Downtime verschmutzt weder deine Uptime-Quote noch den SLA-Report, den dein Kunde sieht, und niemand wird um drei Uhr nachts von deiner eigenen Wartung geweckt. - Ein Wartungsfenster unterdrückt Alarme für ausgewählte Monitore in einem geplanten Zeitraum, statt ganze Accounts stummzuschalten. - Fällt ein Ausfall in ein aktives Fenster, zeigt die Status-Seite Wartung statt Down, und die Downtime zählt nicht gegen deine Uptime. - Ziele lassen sich vier Wege setzen: ein Monitor, mehrere Monitore, ein ganzer Kunde oder dynamisch über Tags. - Wiederkehrende Fenster (täglich, wöchentlich, monatlich) decken feste Deployment-Rhythmen mit einer einzigen Konfiguration ab. - Alles per Dashboard oder REST-API, unter deiner Marke, gehostet in der EU. ## Warum geplante Wartung ein eigenes Werkzeug braucht Geplante Wartung ist kein Ausfall, wird von naivem Monitoring aber wie einer behandelt. Sobald du deployst, migrierst oder einen Server neu startest, geht der Dienst kurz offline, der Check schlägt fehl, und die Alarmierung feuert: E-Mail, SMS, Slack, vielleicht ein Anruf über die Eskalationskette. Das Problem ist nicht der einzelne Alarm, sondern das Muster. Wer für jede geplante Wartung Alarme kassiert, stumpft ab und übersieht irgendwann den echten Ausfall. Das ist [Alert Fatigue](/de/ressourcen/plattform-und-support/glossar/alert-fatigue), und sie kostet dich genau dann Reaktionszeit, wenn es zählt. Die naheliegende Notlösung, den betroffenen Account oder Monitor kurz komplett stummzuschalten, ist schlechter als das Problem. Manuelles Stummschalten heißt: daran denken, es wieder einzuschalten. Vergisst du das, läuft der Monitor blind weiter, und ein echter Ausfall nach der Wartung bleibt unbemerkt. Ein Wartungsfenster löst beide Seiten: Es pausiert die Alarmierung nur für den geplanten Zeitraum und nur für die geplanten Ziele, und es schaltet sich am Ende von selbst wieder scharf. Geplante Wartung braucht ein eigenes Werkzeug, weil sie technisch wie ein Ausfall aussieht, geschäftlich aber das Gegenteil ist: ein Beweis, dass du die Infrastruktur aktiv pflegst. ## Was ein Wartungsfenster technisch tut Während ein Wartungsfenster aktiv ist, gilt jeder abgedeckte Monitor als in Wartung. Zwei Dinge passieren gleichzeitig: Es wird kein Alarm gefeuert, und wenn der Kunde eine Status-Seite hat, erscheint der Dienst dort als Wartung statt als Degraded oder Down. Die Prüfungen laufen im Hintergrund weiter, du verlierst also keine Datenpunkte, aber sie lösen keine Eskalation aus und drücken nicht deine Verfügbarkeitsquote. Das ist der entscheidende Unterschied zur Stummschaltung. Stummschalten unterdrückt nur die Benachrichtigung, der Ausfall landet trotzdem als Downtime in der Historie. Ein Wartungsfenster reklassifiziert das Ereignis: Der gleiche fehlgeschlagene Check zählt als Wartung, nicht als Ausfall. Der Kunde, der am Monatsende auf seinen Report schaut, sieht keinen mysteriösen Einbruch der Uptime, sondern eine sauber ausgewiesene, geplante Wartung, die du proaktiv kommuniziert hast. ## Wie du ein Wartungsfenster richtig setzt Ein Wartungsfenster braucht drei Angaben: einen Namen, eine Startzeit und eine Endzeit. Die Endzeit muss nach der Startzeit liegen. Dazu kommt mindestens ein Ziel, also die Monitore, die das Fenster abdecken soll. Optional gibst du eine Beschreibung dazu, die in der Historie mitläuft, etwa "Geplante Schema-Migration Datenbank". Die goldene Regel: Setze das Fenster großzügig um das eigentliche Zeitfenster herum. Plane Puffer für den Vorlauf und für die Verifikation danach ein. Ein Deployment, das du für 30 Minuten ansetzt, bekommt lieber ein 60-Minuten-Fenster, damit ein überziehender Rollback nicht doch noch einen Alarm auslöst. Und formuliere den Namen so, dass dein zukünftiges Ich in der Historie sofort versteht, was hier passiert ist. ### Die vier Wege, Monitore abzudecken Uptimeify kennt vier sich gegenseitig ausschließende Targeting-Modi, wobei sich die Multi-Monitor- und die Tag-Auswahl kombinieren lassen. Welchen du wählst, hängt vom Umfang der Wartung ab. | Modus | Wann du ihn nimmst | | --- | --- | | Einzelner Monitor | Ein gezielter Eingriff an genau einem Dienst, etwa ein einzelner SSL-Wechsel. | | Mehrere Monitore | Eine feste Liste zusammengehöriger Monitore desselben Kunden, etwa Website plus zugehöriger Ping-Check. | | Ganzer Kunde | Ein Rundum-Wartungsfenster über alle Monitore eines Kunden, etwa bei einem Hoster-Wechsel. | | Dynamisch per Tag | Alle Monitore, die ein bestimmtes Tag tragen, auch künftig getaggte. Ideal für "alle Production-Systeme". | Die Tag-Variante ist der stärkste Hebel, wenn du im Portfolio-Maßstab arbeitest. Ein Tag-Fenster wird bei jedem eingehenden Prüfergebnis live ausgewertet: Der Monitoring-Worker löst die aktuellen Tags des Monitors auf und entscheidet dann, welche Fenster greifen. Taggst du einen neuen Monitor nach dem Anlegen des Fensters, fällt er automatisch unter die Abdeckung, ganz ohne das Fenster zu bearbeiten. Entfernst du das Tag, fällt er sofort wieder heraus. Wartungsfenster sind die geplante Seite sauberer Alarmierung. Die ungeplante Seite, Multi-Node-Bestätigung vor jedem echten Alarm, deckt Uptimeify mit smarter Alarmierung ab. ### Wiederkehrende Wartung einmal anlegen Viele Wartungen folgen einem Rhythmus: das Deployment jeden Montagnacht, das Wartungsfenster des Hosters am ersten Sonntag im Monat. Für diese Fälle konfigurierst du ein Fenster als wiederkehrend, statt es jede Woche neu zu setzen. Du wählst die Frequenz (täglich, wöchentlich oder monatlich), ein Intervall (jede N-te Periode), und je nach Frequenz feste Wochentage oder einen Tag im Monat. Optional stoppt die Wiederholung an einem festen Enddatum, etwa wenn ein Migrationsprojekt terminiert ist. ## Wartungsfenster in der Praxis: drei typische Szenarien Wo ein Wartungsfenster den Unterschied macht, wird an konkreten Abläufen am deutlichsten. Drei Muster, die im Agentur- und MSP-Alltag immer wieder auftauchen: Beim nächtlichen Deployment legst du ein wiederkehrendes wöchentliches Fenster über die betroffene Website plus ihren Response-Time-Check. Das Deployment läuft, der kurze Ausschlag zählt als Wartung, dein Bereitschaftsdienst schläft durch. Bei der Server-Migration eines Kunden nimmst du den Kunden-Modus und deckst in einem Zug alle seine Monitore ab, statt jeden einzeln zu greifen. Und beim koordinierten Infrastruktur-Freeze über mehrere Kunden hinweg, etwa während eines Rechenzentrums-Umzugs, setzt du ein Tag-Fenster über alle Monitore mit dem Tag "Production", sodass auch die Systeme abgedeckt sind, die dein Team mitten im Freeze noch neu anlegt und taggt. In allen drei Fällen bleibt die [Downtime](/de/ressourcen/plattform-und-support/glossar/downtime) aus der Wartung sauber von echten Vorfällen getrennt. Deine Uptime-Quote bildet weiter die tatsächliche Zuverlässigkeit ab, nicht deinen Wartungskalender. ## Der Conversion-Winkel: Wartung als Vertrauensbeweis Für eine Agentur ist ein Wartungsfenster mehr als ein Ops-Detail. Es ist Teil der Geschichte, die du deinem Kunden erzählst. Eine Status-Seite, die eine geplante Wartung sauber als solche ausweist, statt einen unerklärten Einbruch zu zeigen, signalisiert Kontrolle. Der Kunde sieht: Hier wird nicht nur reagiert, hier wird geplant, angekündigt und kontrolliert eingegriffen. Das ist der Unterschied zwischen "unsere Seite war down" und "unser Dienstleister hat gestern Nacht planmäßig gewartet". Damit schließt sich der Kreis zu zwei anderen Bausteinen. Wartungsfenster sind die geplante Ergänzung zu [smarter Alarmierung](/de/funktionen/smarte-operationen/smarte-alarme), die auf der ungeplanten Seite dafür sorgt, dass nur echte Ausfälle einen Alarm auslösen. Und sie sind das, was deine [Status-Seiten](/de/funktionen/vertrauen-und-compliance/transparency-as-a-service) glaubwürdig macht: eine Statusanzeige, die zwischen Wartung und Ausfall unterscheidet, ist eine, der dein Kunde vertraut. Wer geplante Downtime als Ausfall verbucht, verschenkt genau diesen Vertrauensbeweis. Ein sauber ausgewiesenes Wartungsfenster verwandelt einen technischen Vorgang in ein Verkaufsargument: den Beweis, dass du die Infrastruktur deines Kunden aktiv und planvoll betreust.