Uptime-Überwachung für WordPress: Ausfälle, Fehlerseiten und Zertifikatsablauf früh erkennen

Fällt eine Unternehmenswebsite aus, merkt es oft zuerst ein Kunde, manchmal erst nach Tagen. Bis dahin gehen Anfragen verloren, und in der Suchmaschine sammeln sich Fehlermeldungen. Eine Uptime-Überwachung ruft die Website in festen Abständen von außen auf und meldet sich, sobald etwas nicht stimmt. Entscheidend ist, was genau geprüft wird: Ein Server, der antwortet, ist noch keine funktionierende WordPress-Website. Diese Anleitung zeigt, welche Prüfungen für WordPress sinnvoll sind, wie Sie einen Überwachungsdienst oder ein eigenes Prüfskript einrichten, die Laufzeit des TLS-Zertifikats im Blick behalten und die Alarmierung mit echten Fehlern testen. Die Fehlerbilder und das Skript haben wir auf einer Testinstanz mit WordPress 7.1.2 geprüft.

Voraussetzungen

• WordPress: eine aktuelle Version, getestet mit WordPress 7.1.2 auf PHP 8.4 und Apache.
• Rolle: Administrator, um für den Test den Wartungsmodus auszulösen und Einstellungen zu prüfen.
• Überwachungssystem außerhalb des Webservers: ein externer Monitoring-Dienst, eine selbst betriebene Instanz von Uptime Kuma auf einem anderen Server oder ein Linux-Rechner mit curl und cron, etwa ein kleiner vServer oder ein NAS im Büro.
• Benachrichtigungsweg: eine E-Mail-Adresse, die nicht auf dem überwachten Server liegt, oder ein Messenger-Kanal.
• Staging-Kopie: für den Alarmtest in Schritt 6, damit Sie keine Fehler auf der Live-Website auslösen.
• Backup: eine aktuelle Sicherung von Dateien und Datenbank. Für die Überwachung selbst ändern Sie nichts an WordPress, für den Fehlertest auf Staging schon.

Schritt 1: Festlegen, was „erreichbar“ bedeutet

Ein reiner Ping prüft nur, ob der Server im Netz ist. Ein HTTP-Aufruf prüft, ob der Webserver antwortet. Für WordPress reicht beides nicht, denn die typischen Ausfälle entstehen in PHP und in der Datenbank. Im Labor haben wir die häufigsten Fehlerbilder nachgestellt und die Antworten gemessen:

Zustand	HTTP-Status	Sichtbare Meldung
Normalbetrieb	200	Website
Kritischer PHP-Fehler in einem Plugin	500	„Auf dieser Website ist ein kritischer Fehler aufgetreten.“
Falsches Datenbankpasswort	500	„Error establishing a database connection“
Hängengebliebenes Update (.maintenance)	503 mit Retry-After: 600	Wartungsseite
PHP antwortet nicht rechtzeitig	keine Antwort	Zeitüberschreitung

Diese Fälle erkennt jede Überwachung, die auf Status 200 besteht. Es gibt aber Fehler, bei denen der Server weiterhin 200 liefert: eine leere Seite nach einem Theme-Problem, eine Seite eines Hosters („Domain geparkt“) nach einem DNS-Fehler oder eine manipulierte Startseite. Deshalb prüfen Sie zusätzlich ein Stichwort, das nur auf Ihrer funktionierenden Seite steht. Geeignet ist der Firmenname im Seitentitel oder ein fester Text im Footer. Ungeeignet sind Texte, die sich oft ändern, oder Wörter, die auch auf Fehlerseiten stehen.

Sinnvolle Ziele für kleine Unternehmen:

• die Startseite mit Stichwort,
• eine wichtige Unterseite, etwa das Kontaktformular oder der Shop,
• das Ablaufdatum des TLS-Zertifikats.

Verifizieren: Sie haben für jede Adresse ein Stichwort notiert und mit curl -s https://www.ihre-firma.de/ | grep -c "Ihre Firma GmbH" geprüft, dass es im Quelltext vorkommt (Ergebnis größer als 0).

Schritt 2: Den Standort der Überwachung wählen

Eine Überwachung auf dem Webserver selbst schweigt genau dann, wenn der Server ausfällt. Die Prüfung muss deshalb von außen kommen. Es gibt drei Wege:

• Externer Monitoring-Dienst: schnell eingerichtet, prüft oft von mehreren Standorten. Sie geben dafür Adressen und Kontaktdaten an einen weiteren Anbieter, für die Abrufe selbst fallen keine Besucherdaten an.
• Uptime Kuma auf einem eigenen Server: volle Kontrolle, viele Benachrichtigungswege, aber ein weiteres System, das Sie pflegen müssen. Die Installation beschreibt Uptime Kuma installieren.
• Eigenes Prüfskript per cron: minimal, auf jedem Linux-Rechner lauffähig, siehe Schritt 4.

Liegt das Überwachungssystem beim selben Hoster wie die Website, meldet es Ausfälle des Webservers, aber keinen Ausfall des gesamten Rechenzentrums. Für kleine Unternehmen ist das meist ein akzeptabler Kompromiss, ein NAS im Büro als Prüfstandort vermeidet ihn.

Verifizieren: Das gewählte System läuft nicht auf dem Webserver und nutzt für Benachrichtigungen keinen Mailserver auf dem Webserver.

Schritt 3: Einen Monitor mit Stichwort anlegen

Die Begriffe unterscheiden sich je nach Dienst, die Einstellungen sind überall ähnlich. In Uptime Kuma heißen sie auf Deutsch: „Neuen Monitor hinzufügen“, „Monitortyp“, „Anzeigename“, „URL“, „Schlüsselwort“, „Heartbeat-Intervall“, „Wiederholungen“ und „Benachrichtigung bei Zertifikatsablauf“. Empfohlene Werte:

Einstellung	Wert	Begründung
Typ	HTTP(s) mit Schlüsselwort	erkennt auch Fehler mit Status 200
URL	die endgültige Adresse, z. B. https://www.ihre-firma.de/	ohne Umleitung von http oder ohne www
Schlüsselwort	Firmenname aus dem Seitentitel	siehe Schritt 1
Intervall	60 bis 300 Sekunden	kürzer erzeugt nur Last
Wiederholungen	1 bis 2	kein Alarm bei einem einzelnen Aussetzer
Zeitüberschreitung	10 bis 30 Sekunden	langsame Seiten sind auch ein Problem
Zertifikatsablauf	einschalten	siehe Schritt 5

Als Benachrichtigung eignet sich ein Kanal, den mehrere Personen sehen, etwa ein gemeinsames Postfach oder eine Messenger-Gruppe. Eine einzelne Adresse im Urlaub hilft niemandem.

Verifizieren: Der Monitor zeigt den Status „aktiv“ beziehungsweise grün, und eine Testbenachrichtigung über die Schaltfläche „Testen“ kommt im gewählten Kanal an.

Schritt 4: Alternativ ein eigenes Prüfskript einrichten

Wer keinen weiteren Dienst betreiben möchte, erreicht mit curl und cron dasselbe Grundprinzip. Das folgende Skript prüft Erreichbarkeit, Statuscode 200 und Stichwort. Es gibt nur bei Fehlern etwas aus, cron verschickt dann eine E-Mail an den Benutzer, sofern auf dem Rechner ein Mailversand eingerichtet ist.

#!/bin/sh
# Prüft Statuscode, Stichwort und Antwortzeit einer WordPress-Seite.
# Gibt nur bei Fehlern etwas aus, damit cron nur dann eine E-Mail schickt.
URL="$1"; WORT="$2"; MAX="${3:-10}"
TMP=$(mktemp)
OUT=$(curl -s -o "$TMP" -w "%{http_code} %{time_total}" --max-time "$MAX" "$URL")
RC=$?
CODE=${OUT% *}; ZEIT=${OUT#* }
if [ $RC -ne 0 ]; then echo "FEHLER $URL: keine Antwort (curl-Code $RC)"; rm -f "$TMP"; exit 2; fi
if [ "$CODE" != "200" ]; then echo "FEHLER $URL: HTTP $CODE"; rm -f "$TMP"; exit 2; fi
if ! grep -q "$WORT" "$TMP"; then echo "FEHLER $URL: Stichwort \"$WORT\" fehlt"; rm -f "$TMP"; exit 2; fi
rm -f "$TMP"
[ -n "$VERBOSE" ] && echo "OK $URL: HTTP $CODE in ${ZEIT}s"
exit 0

Speichern Sie es als /usr/local/bin/wp-check.sh, machen Sie es mit chmod +x /usr/local/bin/wp-check.sh ausführbar und testen Sie es:

VERBOSE=1 /usr/local/bin/wp-check.sh https://www.ihre-firma.de/ "Ihre Firma GmbH"

Im Labor lieferte das Skript im Normalbetrieb OK ...: HTTP 200 in 0.103400s und Exit-Code 0. Die Fehlerfälle meldete es so:

FEHLER http://localhost/: HTTP 500
FEHLER http://localhost/: keine Antwort (curl-Code 28)
FEHLER http://localhost/: keine Antwort (curl-Code 7)
FEHLER http://localhost/: Stichwort "Impressum" fehlt
FEHLER http://localhost/: HTTP 301

Code 28 bedeutet Zeitüberschreitung, Code 7 eine abgelehnte Verbindung. Die letzte Zeile zeigt eine Umleitung, das Skript folgt bewusst keinen Umleitungen. Tragen Sie deshalb die endgültige Adresse ein. Dann meldet das Skript auch, wenn eine Umleitung plötzlich woanders hinzeigt. Den Zeitplan legen Sie mit crontab -e an, hier alle fünf Minuten:

MAILTO=technik@ihre-firma.de
*/5 * * * * /usr/local/bin/wp-check.sh https://www.ihre-firma.de/ "Ihre Firma GmbH"

Der Trade-off: Das Skript alarmiert bei jedem Fehlschlag erneut, also alle fünf Minuten, und kennt keine Wiederholungen. Für eine Website reicht das, für viele Adressen ist ein Werkzeug wie Uptime Kuma übersichtlicher.

Verifizieren: VERBOSE=1 liefert eine OK-Zeile, ohne VERBOSE bleibt die Ausgabe leer, und mit einem absichtlich falschen Stichwort erscheint eine FEHLER-Zeile mit Exit-Code 2.

Schritt 5: Das TLS-Zertifikat überwachen

Ein abgelaufenes Zertifikat legt die Website für Besucher ebenso lahm wie ein Serverausfall, der Browser zeigt eine Warnseite. Automatische Verlängerungen scheitern gelegentlich, etwa nach einem DNS-Umzug. Viele Monitoring-Dienste prüfen das Ablaufdatum mit. Mit OpenSSL geht es auch per Skript:

echo | openssl s_client -connect www.ihre-firma.de:443 -servername www.ihre-firma.de 2>/dev/null \
  | openssl x509 -noout -enddate -checkend 1209600

-checkend 1209600 prüft, ob das Zertifikat in den nächsten 14 Tagen abläuft. Im Test mit einem Zertifikat, das in zehn Tagen ablief, meldete OpenSSL „Certificate will expire“ mit Exit-Code 1. Bei ausreichender Laufzeit lautet die Meldung „Certificate will not expire“ mit Exit-Code 0. Hängen Sie die Zeile einmal täglich in cron ein. Mehr zu HTTPS und Zertifikaten steht in WordPress auf HTTPS umstellen.

Verifizieren: Der Befehl zeigt ein Datum hinter notAfter=, das mehr als 14 Tage in der Zukunft liegt, und endet mit „Certificate will not expire“.

Schritt 6: Die Alarmierung mit echten Fehlern testen

Eine Überwachung, die nie ausgelöst hat, ist ungeprüft. Richten Sie einen zweiten Monitor auf Ihre Staging-Kopie ein und stellen Sie dort die Fehler aus Schritt 1 nach:

1. Wartungsmodus: Legen Sie im WordPress-Hauptverzeichnis eine Datei .maintenance mit dem Inhalt <?php $upgrading = time(); ?> an. Die Seite antwortet mit 503. Datei danach löschen.
2. Kritischer Fehler: Legen Sie unter wp-content/mu-plugins/ eine Datei mit einem fehlerhaften Funktionsaufruf an. Die Seite antwortet mit 500. Datei danach löschen.

echo '<?php $upgrading = time(); ?>' > .maintenance
curl -sI https://staging.ihre-firma.de/ | head -1
rm .maintenance

Messen Sie, wie lange es bis zur Benachrichtigung dauert. Bei einem Intervall von 60 Sekunden und einer Wiederholung sind zwei bis drei Minuten zu erwarten.

Der Alarm ist nur die halbe Arbeit. Legen Sie fest, wer reagiert und was als Erstes zu tun ist: Status prüfen, letzte Änderung zurücknehmen, notfalls Backup zurückspielen. Die Diagnose beschreibt Update-Fehler beheben: weiße Seite und kritischer Fehler. Die meisten Ausfälle folgen auf Updates oder Änderungen, eine Überwachung gehört deshalb zur laufenden Pflege dazu. Wer Updates und Sicherungen nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher.

Verifizieren: Für beide Testfehler kam eine Benachrichtigung an, nach dem Entfernen der Datei eine Entwarnung, und die Reaktionszeit ist notiert.

Typische Fehler

• Überwachung nur auf Status 200 ohne Stichwort: Geparkte Domains, leere Seiten und manipulierte Startseiten bleiben unbemerkt.
• Dauerhaft „HTTP 301“: Die überwachte Adresse leitet um, etwa von http auf https oder auf www. Endgültige Adresse eintragen.
• Stichwort fehlt, obwohl die Seite im Browser funktioniert: Das Stichwort wird per JavaScript nachgeladen oder enthält ein HTML-kodiertes Zeichen wie &. Stichwort im Quelltext mit curl prüfen.
• Keine Mail bei Ausfall: Der Alarm läuft über den Mailserver des überwachten Servers oder cron hat keinen Mailversand. Anderen Kanal wählen.
• Alarmflut bei kurzen Aussetzern: Wiederholungen auf 1 oder 2 setzen, Intervall nicht unter 60 Sekunden.
• Überwachung stört die Statistik oder Sicherheits-Plugins: Häufige Abrufe erscheinen in Zugriffsstatistiken und können Firewall-Regeln auslösen. IP-Adresse des Prüfsystems dort ausnehmen.

Häufige Fragen

Reicht der Website-Zustand in WordPress nicht aus?

Nein. Der Bildschirm unter Werkzeuge → Website-Zustand prüft Konfiguration und Sicherheit von innen. Ist WordPress ausgefallen, lässt er sich nicht aufrufen und meldet nichts.

Informiert WordPress nicht selbst bei einem kritischen Fehler?

WordPress versucht bei einem kritischen Fehler, eine E-Mail mit einem Link zum Wiederherstellungsmodus an die Administrator-Adresse zu senden. Das setzt einen funktionierenden Mailversand voraus und erfasst weder Datenbankfehler noch Serverausfälle.

Wie oft sollte geprüft werden?

Für eine Firmenwebsite reichen ein bis fünf Minuten. Häufigere Prüfungen erkennen Ausfälle kaum früher und erzeugen Last und Fehlalarme.

Testumfang

Wir haben in einer Testumgebung mit WordPress 7.1.2 typische Ausfälle nachgestellt, etwa den Wartungsmodus oder ein falsches Datenbankpasswort, und das Prüfskript dagegen laufen lassen. Auch die Zertifikatsprüfung mit openssl -checkend haben wir mit einem Testzertifikat und einem öffentlichen Zertifikat ausprobiert.

Uptime Kuma selbst und den Mailversand über cron haben wir nicht getestet, die deutschen Bezeichnungen stammen aus der Sprachdatei des Projekts. Prüfen Sie diese beiden Teile deshalb selbst, bevor Sie sich im Ernstfall auf die Benachrichtigung verlassen.

Fazit

Eine gute Uptime-Überwachung für WordPress prüft von außen, verlangt Status 200 und ein Stichwort, behält das Zertifikat im Blick und wurde mindestens einmal mit einem echten Fehler ausgelöst. Ob Sie dafür einen Dienst, Uptime Kuma oder ein kurzes Skript nutzen, ist zweitrangig. Wichtiger ist, dass jemand den Alarm sieht und weiß, was zu tun ist. Soll die technische Pflege mit Updates und Backups dauerhaft jemand übernehmen, finden Sie das bei der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• Uptime Kuma installieren: Monitoring mit Docker
• Update-Fehler beheben: weiße Seite und kritischer Fehler
• WordPress auf HTTPS umstellen
• WordPress Advanced Administration: Debugging in WordPress
• curl-Handbuch und OpenSSL x509
• Uptime Kuma auf GitHub