Uptime Monitoring Checkliste: Was wirklich reingehört

15. Oktober 2026 · 5 Min. Lesezeit

Die meisten Monitoring-Setups entstehen in fünf Minuten: URL eintragen, Mailadresse hinterlegen, Haken dran. Das funktioniert, bis der erste Ausfall kommt, den niemand gemeldet bekommt, weil der Server brav HTTP 200 geliefert hat und die Seite trotzdem leer war.

Diese Checkliste geht die Punkte durch, an denen solche Setups typischerweise auseinanderfallen. Kein Pflichtprogramm, sondern eine Liste zum Durchgehen: Was davon brauchst du, was ist bei dir schon geregelt, was fehlt?

Schritt 1: Definiere, was „oben“ bei dir bedeutet

Bevor du irgendeinen Check anlegst, beantworte für jeden Dienst eine Frage: Woran würde ein echter Nutzer merken, dass etwas kaputt ist?

Bei einem Shop ist das nicht die Startseite, sondern der Warenkorb und die Zahlungsstrecke. Bei einer API ist es ein Endpunkt, der tatsächlich die Datenbank anfasst, nicht /health, das nur „ok“ zurückgibt. Bei einem WordPress-Blog ist es oft die Suche oder eine dynamische Seite, weil statisch ausgelieferte Caches noch antworten, wenn PHP längst im Timeout hängt.

Schreib dir diese Antwort pro Dienst auf. Aus ihr folgt der Rest der Checkliste fast von selbst.

Schritt 2: Die Prüfung selbst

HTTP-Status allein reicht selten

Ein 200er sagt nur: Irgendein Prozess hat irgendetwas ausgeliefert. Häufige Fehlerbilder, die dabei durchrutschen:

Die WordPress-Datenbank ist weg, ausgeliefert wird eine Fehlerseite mit Status 200.
Ein Deployment hat ein leeres Template hochgeladen, die Seite ist 0 KB groß und technisch korrekt.
Der Reverse Proxy liefert eine Wartungsseite aus, die ebenfalls sauber antwortet.
Eine Weiterleitung landet im Loop, der Client sieht nach mehreren Hops nichts Brauchbares.

Die Gegenmaßnahme ist eine Inhaltsprüfung: Ein Text, der nur erscheint, wenn die Anwendung wirklich funktioniert. Der Produktname im Footer taugt dafür schlecht, weil er oft auch auf der Fehlerseite steht. Besser ist etwas, das aus der Datenbank kommt. Ausführlicher steht das in uptime monitoring, was es prüft und wo es aufhört.

Zertifikate rechtzeitig, nicht am Ablauftag

Ein abgelaufenes TLS-Zertifikat ist ein Totalausfall mit Browser-Warnung, und zwar einer, der sich ankündigt. Trotzdem gehört ein Blick in die Renewal-Logs selten zur Routine. Auf die Checkliste: Wird die Restlaufzeit überwacht, und wann kommt die Warnung? Eine Warnung zwei Wochen vor Ablauf gibt dir Zeit, einen hängenden Certbot-Timer zu reparieren, bevor es hektisch wird. Dafür gibt es SSL-Monitoring als eigenen Check-Typ.

Alles, was kein HTTP spricht

Mailserver, Datenbank-Port, SSH, Gameserver, SMTP-Relay: Diese Dienste tauchen in HTTP-basierten Setups gar nicht erst auf. Wenn bei dir ein Port auf Port 25 oder 5432 lauscht, von dem Kunden abhängen, gehört er über einen TCP-Check auf die Liste.

Langsam ist ein eigener Zustand

Eine Seite, die nach 14 Sekunden antwortet, ist formal erreichbar. Für Nutzer ist sie es nicht, und für Google auch nicht. Wenn dein Monitoring nur zwischen „antwortet“ und „antwortet nicht“ unterscheidet, siehst du den Tag nicht, an dem die Antwortzeit von unter einer Sekunde auf sechs Sekunden klettert, weil ein Index fehlt. Setz dir eine Schwelle und lass sie separat melden, siehe Erkennung langsamer Antworten.

Schritt 3: Intervall, Timeout, Bestätigung

Drei Zahlen, die zusammen bestimmen, wie schnell und wie nervig dein Monitoring ist.

Intervall. Eine Minute für alles, woran Umsatz hängt. Fünf Minuten für interne Tools und Projektseiten. Alles darüber bedeutet, dass ein Ausfall im schlimmsten Fall so lange unbemerkt läuft wie dein Intervall lang ist, plus die Zeit bis zur Bestätigung.

Timeout. Setz ihn höher als die schlechteste Antwortzeit, die du im Normalbetrieb akzeptierst, aber nicht beliebig hoch. Ein Timeout von 30 Sekunden verzögert die Erkennung eines hängenden Dienstes um genau diese 30 Sekunden.

Bestätigung. Ein einzelner fehlgeschlagener Request ist kein Ausfall. Paketverlust, ein neu startender Worker, ein kurzer DNS-Hänger: Wenn jeder dieser Fälle eine Push-Nachricht auslöst, schaltet man die Benachrichtigungen irgendwann stumm. Eine zweite Prüfung nach kurzer Wartezeit, idealerweise von einem anderen Standort aus, filtert einen großen Teil dieser Fehlalarme weg. Wie man das sauber aufzieht, steht in Website richtig prüfen und alarmieren.

Schritt 4: Wer wird wann benachrichtigt

Hier scheitern Setups am häufigsten, und zwar leise. Punkte zum Abhaken:

Geht der Alarm an einen Kanal, den du außerhalb der Bürozeiten tatsächlich siehst? E-Mail auf ein Postfach, das nachts niemand öffnet, ist Dokumentation, keine Alarmierung.
Gibt es einen zweiten Empfänger, wenn der erste im Urlaub ist?
Kommt eine Entwarnung, wenn der Dienst wieder läuft? Ohne Recovery-Meldung weiß man morgens nicht, ob das Problem noch besteht.
Hängt die Alarmierung am selben Server wie der überwachte Dienst? Dann fällt beides gemeinsam aus.
Sind Ruhezeiten definiert, und zwar unterschiedlich je Dienst? Der Produktionsshop darf um drei Uhr nachts klingeln, die Staging-Umgebung nicht.

Eine eigene Meinung dazu: Lieber wenige Checks mit scharfer Alarmierung als zwanzig Checks, deren Meldungen in einem Sammelkanal versickern. Ein Alarm, den du ignorierst, ist schlimmer als kein Alarm, weil er dir Sicherheit vortäuscht.

Schritt 5: Wartungsfenster und Kommunikation

Geplante Deployments erzeugen Ausfälle, die niemand gemeldet bekommen muss. Wenn dein Setup keine Stummschaltung kennt, lernst du schnell, Alarme während Wartungen wegzuwischen, und wischst irgendwann den echten weg.

Dazu gehört die Frage, wer außer dir Bescheid wissen muss. Kunden, die bei einem Ausfall im Support anrufen, kosten mehr Zeit als eine Statusseite, die den Vorfall von sich aus zeigt. Für kleine Dienste reicht oft eine Seite, die den aktuellen Zustand der wichtigsten Endpunkte listet, plus die Historie der letzten Tage.

Was diese Checkliste nicht abdeckt

Uptime Monitoring von außen sieht die Symptome, nicht die Ursachen. Ein voll laufendes Dateisystem, ein Speicherleck, das in drei Tagen zum Absturz führt, eine kaputte Backup-Rotation: Das bemerkt ein externer Check erst, wenn es zu spät ist. Dafür brauchst du Metriken vom Host selbst.

Auch selbstgebaute Lösungen haben ihre Grenzen. Ein Cron-Job in GitHub Actions, der regelmäßig curl aufruft, funktioniert für einen Hobby-Dienst ganz ordentlich, ist aber primär als Automations-Plattform gedacht und nicht als Alarmierungssystem mit Eskalation und Ruhezeiten. Die Details dazu stehen in Uptime Monitoring mit GitHub-Tools.

Die Kurzfassung zum Durchgehen

Pro Dienst festgelegt, welcher Endpunkt echten Ausfall anzeigt
Inhaltsprüfung statt reinem Statuscode, wo die Anwendung dynamisch ist
Zertifikatslaufzeit überwacht, mit Vorwarnzeit
Nicht-HTTP-Dienste über Port-Checks abgedeckt
Schwelle für langsame Antworten definiert
Intervall passend zur Kritikalität, Timeout bewusst gesetzt
Bestätigungsprüfung aktiv, damit einzelne Aussetzer keinen Alarm auslösen
Alarmkanal, der nachts wirklich ankommt, plus zweiter Empfänger
Recovery-Meldung aktiviert
Wartungsfenster stummschaltbar
Statusseite für alle, die sonst im Support anrufen

Wenn du die Punkte einmal durchgehst und dabei feststellst, dass die Hälfte davon in deinem aktuellen Setup fehlt: Der Uptime Alien deckt genau diese Prüfungen ab, und in der Demo siehst du ohne Anmeldung, wie das aussieht.