--- title: "Uptime-Überwachung für WordPress: Ausfälle, Fehlerseiten und Zertifikatsablauf früh erkennen" date: 2026-09-30T22:04:16+02:00 modified: 2026-11-10T08:55:05+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-uptime-ueberwachung-ausfaelle-frueh-erkennen keywords: - WordPress - Monitoring - Uptime - Wartung - curl reading_time: 9 --- # 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. **Kurzfassung:** Überwachen Sie die Startseite mit Statuscode 200 und einem Stichwort, das nur auf der funktionierenden Seite steht, etwa den Namen Ihrer Firma im Seitentitel. WordPress liefert bei einem kritischen Fehler und bei einem Datenbankfehler Status 500, im Wartungsmodus Status 503. Die Prüfung muss von einem System außerhalb Ihres Webservers laufen. Prüfen Sie alle ein bis fünf Minuten, alarmieren Sie erst nach einem bestätigten Fehlschlag und überwachen Sie zusätzlich das Ablaufdatum des Zertifikats. Testen Sie die Alarmierung einmal bewusst auf einer Staging-Kopie. ## 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. Die folgenden Beispiele zeigen die häufigsten Fehlerbilder und die gemessenen Antworten: | 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. > **Prüfen:** 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](https://s-edv.com/anleitungen/uptime-kuma-installieren-docker-nginx-proxy-manager). - **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. > **Prüfen:** 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. > **Prüfen:** 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. ```bash #!/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: ```bash VERBOSE=1 /usr/local/bin/wp-check.sh https://www.ihre-firma.de/ "Ihre Firma GmbH" ``` Im Test lieferte das Skript im Normalbetrieb `OK ...: HTTP 200 in 0.103400s` und Exit-Code 0. Die Fehlerfälle meldete es so: ```plaintext 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: ```plaintext 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. > **Prüfen:** `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: ```bash 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](https://s-edv.com/anleitungen/wordpress-https-umstellen-ssl-mixed-content-beheben). > **Prüfen:** 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 `` 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. ```bash $ echo '' > .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](https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=75) spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher. > **Prüfen:** 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. ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=75). ## Weiterführende Anleitungen und Quellen - [Uptime Kuma installieren: Monitoring mit Docker](https://s-edv.com/anleitungen/uptime-kuma-installieren-docker-nginx-proxy-manager) - [Update-Fehler beheben: weiße Seite und kritischer Fehler](https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-kritischer-fehler) - [WordPress auf HTTPS umstellen](https://s-edv.com/anleitungen/wordpress-https-umstellen-ssl-mixed-content-beheben) - [WordPress Advanced Administration: Debugging in WordPress](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) - [curl-Handbuch](https://curl.se/docs/manpage.html) und [OpenSSL x509](https://docs.openssl.org/3.5/man1/openssl-x509/) - [Uptime Kuma auf GitHub](https://github.com/louislam/uptime-kuma)