Uptime-Monitoring einrichten: welche Prüfungen sinnvoll sind
Wer Uptime-Monitoring einrichten will, braucht vier automatische Prüfungen: Erreichbarkeit mit erwartetem Inhalt, Restlaufzeit des Zertifikats, Ablauf der Domain und Heartbeats für geplante Aufgaben. Zu jeder Prüfung gehören ein Intervall und eine Person, die der Alarm erreicht.
Ein Monitoring meldet seit Wochen „online“, und trotzdem kommen keine Bestellungen an. Die Startseite liefert Statuscode 200, zeigt aber eine Fehlermeldung der Datenbank. Oder die Website läuft einwandfrei, während die nächtliche Sicherung seit dem letzten Serverumzug nicht mehr startet. Eine reine Erreichbarkeitsprüfung sieht beides nicht.
Welche Metriken und Dashboards darüber hinaus etwas aussagen, steht unter Monitoring-Mythen: Was Dashboards nicht zeigen. Was nach einem Alarm in der ersten Stunde passiert, regelt der Notfallplan für Ihre Webanwendung.
Prüfung 1
Erreichbarkeit ist nur die erste Prüfung
Eine Erreichbarkeitsprüfung ruft eine Adresse von außen auf und bewertet die Antwort. Der Statuscode allein reicht dafür nicht, denn manche Anwendungen liefern auch Fehlerseiten mit 200 aus. Lassen Sie den Dienst deshalb zusätzlich nach einem Text suchen, der nur auf einer funktionierenden Seite steht, etwa dem Namen eines Produkts aus der Datenbank oder einer Zeile aus dem Seitenfuß.
Prüfen Sie neben der Startseite die Seite, an der Umsatz oder Anfragen hängen: Warenkorb, Anmeldung, Kontaktformular. Eine Startseite aus dem Cache kann erreichbar bleiben, auch wenn Datenbank oder Sitzungsspeicher ausgefallen sind. Ein eigener Prüfpfad in der Anwendung, der kurz die Datenbank abfragt und „ok“ zurückgibt, deckt diesen Fall ab. Zu jeder Prüfung gehört ein Zeitlimit: Eine Seite, die nach 30 Sekunden antwortet, ist für Besucher ausgefallen.
Überblick
Was geprüft wird, wie oft und wer den Alarm bekommt
Die Intervalle sind unsere Empfehlung für eine Website oder Webanwendung mit Kunden im Tagesgeschäft. Bei einer reinen Informationsseite dürfen die Abstände größer sein.
| Sinnvolles Intervall | Wer den Alarm bekommt | |
|---|---|---|
| Startseite mit erwartetem Text | 1 bis 5 Minuten, aus mindestens zwei Standorten | Betrieb der Anwendung, außerhalb der Geschäftszeiten die Rufbereitschaft |
| Seite mit Umsatzbezug (Warenkorb, Anmeldung, Formular) | 1 bis 5 Minuten | Betrieb, bei längerem Ausfall zusätzlich die fachlich verantwortliche Person |
| Prüfpfad mit Datenbankabfrage | 1 bis 5 Minuten | Betrieb |
| Restlaufzeit des TLS-Zertifikats | täglich, Warnung unter 14 Tagen Restlaufzeit | Betrieb oder Hoster, wer die Zertifikate verwaltet |
| Ablauf der Domain | wöchentlich, Warnung ab 60 Tagen | Person, die den Vertrag mit dem Registrar verwaltet |
| Heartbeat für Sicherung, Import oder Rechnungslauf | je Lauf, mit Karenzzeit über der normalen Laufzeit | Betrieb, beim Rechnungslauf zusätzlich die Buchhaltung |
Prüfung 2 und 3
Zertifikat und Domain im Blick behalten
Ein abgelaufenes TLS-Zertifikat sperrt Besucher mit einer Browserwarnung aus, obwohl der Server läuft. Auf Erinnerungen der Zertifizierungsstelle können Sie sich nicht verlassen: Let's Encrypt hat den Versand von Ablauf-E-Mails am 04.06.2025 eingestellt und verweist seitdem auf externe Überwachung. Dazu kommen kürzere Laufzeiten: Let's Encrypt hat angekündigt, die Gültigkeit seiner Zertifikate in mehreren Stufen von 90 auf 45 Tage zu senken, und bietet 45 Tage seit dem 13.05.2026 als wählbares Profil an.
Das Skript unten holt das Zertifikat mit curl, das dabei Kette und Hostnamen prüft und nach zehn Sekunden abbricht, und lässt openssl die Restlaufzeit bewerten. Ein abgelaufenes oder falsch ausgestelltes Zertifikat endet mit Exit-Code 2, eines mit weniger als 14 Tagen Restlaufzeit mit 1. Die Schwelle liegt bewusst unter dem Zeitpunkt der regulären Verlängerung: Certbot erneuert seit Version 4.0.0, wenn weniger als ein Drittel der Laufzeit übrig ist, bei 90 Tagen also nach 60 Tagen, bei 45 Tagen nach 30. Meldet das Skript eine Warnung, ist die automatische Verlängerung mindestens einmal ausgeblieben.
Der Befehl eignet sich als täglicher Cronjob; den Exit-Code meldet der Heartbeat aus dem nächsten Abschnitt an den Überwachungsdienst.
#!/usr/bin/env bash
# Checks the TLS certificate of a host.
# Usage: check-cert.sh <host> [days] (warn if it expires within <days>, default 14)
# Exit codes: 0 ok, 1 expires soon, 2 cannot be checked, 64 wrong usage
set -uo pipefail
host="${1:?usage: check-cert.sh <host> [days]}"
days="${2:-14}"
case "$days" in ''|*[!0-9]*) echo "days must be a whole number" >&2; exit 64 ;; esac
# curl verifies chain and host name; -m 10 stops a hanging connection.
chain="$(curl -sS -m 10 -o /dev/null -w '%{certs}' "https://$host/")" \
|| { echo "CRITICAL: $host: connection or certificate verification failed" >&2; exit 2; }
leaf="$(printf '%s\n' "$chain" | openssl x509 2>/dev/null)" \
|| { echo "CRITICAL: $host: no certificate in curl output (needs curl 7.88 or newer)" >&2; exit 2; }
end="$(printf '%s\n' "$leaf" | openssl x509 -noout -enddate | cut -d= -f2)"
if printf '%s\n' "$leaf" | openssl x509 -noout -checkend $(( days * 86400 )) >/dev/null; then
echo "OK: $host valid until $end"
else
echo "WARNING: $host expires within $days days ($end)" >&2
exit 1
fi
Ablaufdatum der Domain
Bei der Domain hängt die Prüfung an der Endung. Für .com-Domains liefert die Abfrage über RDAP, den Nachfolger von whois, ein Ereignis „expiration“ mit Datum, das ein Skript auswerten kann. Die DENIC nennt bei .de-Domains in ihrer RDAP-Abfrage den Status, technische Daten und das Datum der letzten Änderung, aber kein Ablaufdatum. Dort hilft eine Erinnerung im Kalender der Person, die Vertrag und Zahlungsweg beim Registrar verwaltet. Eine Domain kann auch verfallen, weil nur die hinterlegte Kreditkarte abgelaufen ist.
Prüfung 4
Geplante Aufgaben mit Heartbeats überwachen
Sicherungen, Datenimporte und Rechnungsläufe laufen nachts. Fallen sie aus, meldet sich niemand, denn ein Cronjob, der nicht startet, erzeugt keinen Fehler. Ein Heartbeat dreht die Logik um: Die Aufgabe meldet sich nach jedem Lauf bei einem Überwachungsdienst, und der Dienst schlägt Alarm, wenn die Meldung ausbleibt oder einen Fehler enthält.
Das Skript unten umschließt einen beliebigen Befehl. Es meldet den Start, führt den Befehl aus und schickt danach dessen Exit-Code. Die Adressform mit /start und /<exit-code> stammt von Healthchecks.io; dort zählt 0 als Erfolg und jeder Wert von 1 bis 255 als Fehler. Andere Dienste nutzen eigene Adressen. Jede Meldung bekommt zehn Sekunden pro Versuch und bis zu fünf Wiederholungen, insgesamt höchstens rund eine Minute. Scheitert die Meldung, läuft die Aufgabe trotzdem durch und behält ihren Exit-Code.
Ein Aufruf ohne Befehl endet mit Exit-Code 64; ist der Überwachungsdienst nicht erreichbar, steht ein Hinweis im Log der Aufgabe, und der Dienst meldet den fehlenden Heartbeat.
#!/usr/bin/env bash
# Runs a command and reports start and exit status to a heartbeat URL.
# Usage: heartbeat.sh <ping-url> <command> [args...]
set -uo pipefail
url="${1:?usage: heartbeat.sh <ping-url> <command> [args...]}"
shift
[ "$#" -gt 0 ] || { echo "usage: heartbeat.sh <ping-url> <command> [args...]" >&2; exit 64; }
ping_url() {
# 10 s per attempt, up to 5 retries, at most 60 s in total.
# A failed ping is logged but never stops or changes the job itself.
curl -fsS -m 10 --retry 5 --retry-max-time 60 -o /dev/null "$1" \
|| echo "heartbeat: ping failed: $1" >&2
}
ping_url "$url/start"
"$@"
status=$?
ping_url "$url/$status" # 0 = success, 1 to 255 = failure
exit "$status"
Die Sicherung läuft jede Nacht um 02:15 Uhr; im Überwachungsdienst stellen Sie dafür einen täglichen Zeitplan und eine Karenzzeit über der üblichen Laufzeit ein.
MAILTO=""
15 2 * * * /usr/local/bin/heartbeat.sh https://hc-ping.com/<your-check-uuid> /usr/local/bin/backup-db.sh >> /var/log/backup-db.log 2>&1
Cron-Zeile und Laravel-Scheduler
cron wandelt ein Prozentzeichen in einer Crontab-Zeile in einen Zeilenumbruch um; Datumsformate wie +%F im Befehl müssen Sie deshalb mit Backslash schreiben oder in das Skript verlagern. Wer den Laravel-Scheduler nutzt, braucht kein eigenes Skript: Die Methoden pingOnSuccess und pingOnFailure rufen eine Adresse auf, je nachdem, ob der geplante Befehl mit Exit-Code 0 endet. Ob die Sicherung, die der Heartbeat als erfolgreich meldet, sich auch zurückspielen lässt, zeigt erst ein Restore-Test.
Takt
Prüfintervalle und Standorte wählen
Das Intervall legt fest, wie lange ein Ausfall unbemerkt bleibt. Prüft der Dienst alle fünf Minuten und bestätigt er einen Fehler erst mit der nächsten regulären Messung, vergehen im ungünstigsten Fall rund zehn Minuten bis zum Alarm: bis zu fünf Minuten bis zur ersten fehlgeschlagenen Messung, fünf weitere bis zur Bestätigung. Bei einer Minute Abstand sind es rund zwei. Dienste, die sofort nachmessen, verkürzen die zweite Hälfte.
Wichtiger als ein sehr kurzer Takt ist die Bestätigung von einem zweiten Standort. Ein Fehler auf der Netzstrecke zwischen einem einzelnen Prüfstandort und Ihrem Rechenzentrum sieht für diesen Standort aus wie ein Ausfall. Melden zwei Standorte in verschiedenen Netzen denselben Fehler, liegt er mit hoher Wahrscheinlichkeit bei Ihnen. Geplante Wartungsfenster tragen Sie im Dienst als Pause ein, damit eine angekündigte Unterbrechung niemanden nachts weckt.
Zuständigkeit
Wer bei welchem Alarm benachrichtigt wird
Geht ein Alarm an ein Sammelpostfach, bleibt am Wochenende offen, wer ihn liest. Legen Sie für jede Prüfung eine zuständige Person und eine Vertretung fest, dazu den ersten Handgriff: Server neu starten, Hoster anrufen, Zertifikat erneuern. In unserem Incident Management hat jeder Alarm eine verantwortliche Person und einen ersten Handlungsschritt, und Schwellen legen wir mit dem Team des Kunden fest, mit Bezug zu Geschäftszeiten und kritischen Abläufen.
Trennen Sie nach Dringlichkeit. Ein Ausfall der Bestellseite verdient einen Anruf oder eine Push-Nachricht, ein Zertifikat mit 20 Tagen Restlaufzeit eine E-Mail am nächsten Werktag. Sind alle Alarme gleich laut, entsteht Alarmmüdigkeit: Wichtige Meldungen gehen dann zwischen den unwichtigen unter. Testen Sie den Weg einmal im Quartal mit einem absichtlich ausgelösten Alarm, auch nach einem Wechsel der Rufbereitschaft oder einer neuen Telefonnummer.
Zum Einrichten gefragt
Häufige Fragen
-
Für Seiten mit Umsatz oder Kundenkontakt sind ein bis fünf Minuten üblich, bestätigt von einem zweiten Standort. Daraus ergibt sich, wie lange ein Ausfall höchstens unbemerkt bleibt: bei fünf Minuten und einer Bestätigung mit der nächsten Messung rund zehn Minuten.
-
Für eine einzelne Website mit Prüfungen im Fünf-Minuten-Takt reichen die kostenlosen Stufen vieler Dienste technisch aus. Prüfen Sie vorher, ob die Nutzungsbedingungen eine gewerbliche Nutzung erlauben, wo der Dienst seine Daten speichert und ob Alarme per Anruf oder SMS enthalten sind. Achten Sie darauf, dass der Tarif neben Webadressen auch Heartbeats für geplante Aufgaben prüft.
-
Ein Heartbeat-Monitor erwartet in einem festen Rhythmus eine Meldung von Ihrem System, statt selbst eine Adresse aufzurufen. Bleibt die Meldung länger aus als der eingestellte Zeitplan plus Karenzzeit, löst er Alarm aus. Damit lassen sich Cronjobs, Warteschlangen und Sicherungen überwachen, die keine eigene Webadresse haben.
Läuft Ihre nächtliche Sicherung noch?
Wenn Sie Prüfungen, Intervalle und Zuständigkeiten nicht selbst pflegen wollen: Unser Monitoring überwacht Server, Anwendungen und Datenbanken, von der Auslastung bis zu den Abfragezeiten.
Nachweise
Quellen und Stand
Stand: 24.09.2026. Beide Skripte haben wir unter macOS mit bash 3.2, curl 8.7 und LibreSSL 3.3 ausgeführt: das Zertifikats-Skript gegen öffentliche Hosts mit gültigem, abgelaufenem und falsch ausgestelltem Zertifikat, gegen einen nicht auflösbaren Namen und eine nicht antwortende Adresse (Abbruch nach zehn Sekunden), das Heartbeat-Skript gegen einen lokalen Testserver mit erfolgreichem und fehlschlagendem Befehl, mit Fehlerantwort 503, mit verzögerter Antwort und ohne erreichbaren Server. Die Crontab-Zeile ist gegen die Handbuchseite crontab(5) geprüft, nicht auf einem Server eingerichtet.
Let's Encrypt: Ending Support for Expiration Notification Emails (22.01.2025)
Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days (02.12.2025)
Certbot: Dokumentation, Verlängerung bei weniger als einem Drittel Restlaufzeit seit Version 4.0.0
Healthchecks.io: Pinging API, Signale start, fail und Exit-Code
curl: Handbuch, Optionen --max-time, --retry, --retry-max-time und --write-out
Artikel teilen