Uptime Monitoring für WordPress: was wirklich zählt

26. August 2026 · 6 Min. Lesezeit

Eine WordPress-Seite fällt selten so aus, dass sofort alles dunkel ist. Viel häufiger passiert etwas Halbes: Die Startseite lädt, aber der Warenkorb wirft einen Fehler. Der Server antwortet, aber erst nach elf Sekunden. Das SSL-Zertifikat ist abgelaufen, und der Browser zeigt eine Warnseite, die keiner deiner Besucher wegklickt.

Genau solche Fälle sind der Grund, warum Uptime Monitoring bei WordPress etwas anders aussieht als bei einem statischen HTML-Auftritt. WordPress hat viele bewegliche Teile: PHP, eine Datenbank, ein Theme, Plugins, oft ein Caching-Layer und ein CDN davor. Jedes Teil kann einzeln kaputtgehen, ohne den Rest mitzunehmen.

Was bei WordPress typischerweise schiefgeht

Die klassischen Fehlerbilder, die man kennen sollte, bevor man Checks einrichtet:

Der weiße Bildschirm nach dem Update. Ein Plugin-Update kollidiert mit der PHP-Version, WordPress liefert eine leere Seite aus. Der HTTP-Status ist dabei oft weiterhin 200. Ein reiner Erreichbarkeits-Check sagt: alles gut. Deine Besucher sehen: nichts.

Fehler beim Datenbankaufbau. „Error establishing a database connection“ ist eine echte HTML-Seite mit Status 500 oder auch 200, je nach Setup. Auch hier hilft ein Blick auf den Inhalt mehr als auf den Statuscode.

Das abgelaufene Zertifikat. Let's-Encrypt-Zertifikate laufen nach 90 Tagen ab und werden normalerweise automatisch erneuert. Wenn der Cron-Job für die Erneuerung stillschweigend hängt, merkst du es am Tag der Ablauffrist. Meist an einem Sonntag.

Die Seite, die nur noch kriecht. Ein Plugin fragt bei jedem Seitenaufruf eine externe API ab, die langsam geworden ist. Die Seite ist erreichbar, aber unbenutzbar. Uptime-Statistik: 100 Prozent.

Der Cache, der lügt. Ein Full-Page-Cache liefert weiter aus, während PHP schon längst tot ist. Anonyme Besucher merken nichts, eingeloggte Nutzer und der Checkout stehen. Das ist der unangenehmste Fall, weil er sich zwei Tage verstecken kann.

DNS-Probleme nach dem Providerwechsel. Der Server läuft, aber ein Nameserver antwortet nicht mehr oder liefert einen alten A-Record. Für einen Teil deiner Besucher existiert die Seite dann einfach nicht.

Der Standard-Check reicht für WordPress nicht

Ein Basis-Check ruft eine URL auf und prüft, ob eine Antwort kommt. Das ist die Grundlage, und für viele Server ist es genug. Für WordPress ist es die untere Hälfte der Wahrheit.

Sinnvoller ist ein HTTP-Check, der drei Dinge zusätzlich bewertet: den Statuscode, den Inhalt der Antwort und die Antwortzeit. Beim Inhalt geht es um ein Stück Text, das nur da ist, wenn die Seite korrekt gerendert wurde. Nimm nicht „Impressum“ aus dem Footer, wenn das Theme den Footer auch bei halb kaputtem Content ausliefert. Nimm einen String aus dem eigentlichen Seiteninhalt.

Dazu gehört ein Wort zur Antwortzeit. Erreichbar und brauchbar sind zwei Zustände. Wer Alarme nur auf „down“ legt, verpasst die Phase davor, und die dauert manchmal Wochen. Ein Schwellwert für langsame Antworten fängt genau das ab, bevor Besucher abspringen.

Welche Checks du für eine WordPress-Seite einrichten solltest

Eine Liste, die sich an den Bauteilen orientiert und nicht an einer runden Zahl:

Startseite per HTTP, mit Keyword-Prüfung auf einen Inhaltstext.
Eine dynamische, nicht gecachte Seite. Bei WooCommerce etwa eine Cart- oder Account-URL. Diese Route umgeht den Page-Cache und trifft wirklich PHP und Datenbank.
Login-Seite (/wp-login.php). Sie sagt dir, ob WordPress selbst noch antwortet, auch wenn das Frontend aus dem Cache kommt.
REST-API-Endpunkt, etwa /wp-json/. Nützlich, wenn Headless-Frontends, Apps oder Formulare daran hängen. Ein API-Check prüft hier Statuscode und Antwortstruktur.
SSL-Zertifikat mit Vorwarnung, damit du die Erneuerung nachschieben kannst, statt sie zu reparieren.
DNS-Auflösung, besonders nach Migrationen oder wenn du mehrere Nameserver betreibst.
Ein Cronjob-Kanal, wenn Backups oder geplante Aufgaben laufen. Ein Backup, das seit sechs Wochen nicht mehr durchläuft, fällt sonst erst auf, wenn du es brauchst.

Das ist mehr Arbeit als ein Check auf die Domain. Es ist aber die Arbeit, die den Unterschied zwischen „wir wussten es sofort“ und „ein Kunde hat angerufen“ ausmacht.

Warum ein Monitoring-Plugin im WordPress selbst die falsche Stelle ist

Es gibt Plugins, die Uptime und Fehler direkt aus WordPress heraus melden. Die haben einen Konstruktionsfehler, der sich nicht wegkonfigurieren lässt: Wenn WordPress steht, steht auch das Plugin. Der Server ist offline, PHP crasht, die Datenbank antwortet nicht, und die Instanz, die dich warnen soll, ist Teil des Ausfalls.

Uptime Monitoring muss von außen kommen. Immer. Ein Plugin kann sinnvolle Dinge tun (Fehlerprotokolle sammeln, Performance-Daten aus PHP heraus messen, Änderungen an Dateien bemerken), aber es kann dir nicht sagen, dass die Seite unerreichbar ist.

Dazu ein zweiter Punkt, der bei Shared Hosting oft übersehen wird: Prüfintervalle kosten Requests. Wer alle 30 Sekunden eine nicht gecachte WooCommerce-Seite abfragt, erzeugt dauerhaft Last auf PHP und Datenbank. Für die meisten kleineren Seiten sind ein bis fünf Minuten ein vernünftiger Kompromiss. Bei Shops, die pro Minute Umsatz machen, spricht nichts gegen kürzere Intervalle auf einer leichten Route und längere auf den teuren Checks.

Alarme, die man nicht nach zwei Wochen abschaltet

Das häufigste Problem im Monitoring ist nicht der verpasste Ausfall, sondern der ignorierte Alarm. Wenn dein Handy dreimal pro Woche wegen eines 4-Sekunden-Timeouts vibriert, schaltest du die Benachrichtigung irgendwann stumm. Dann ist das Monitoring formal aktiv und praktisch wertlos.

Zwei Einstellungen helfen dagegen mehr als alles andere. Erstens: Bestätigung durch mehrere Fehlversuche, bevor Alarm ausgelöst wird. Ein einzelner fehlgeschlagener Request kann jede Ursache haben, zwei oder drei hintereinander sind ein Signal. Zweitens: getrennte Schweregrade. Ein abgelaufenes Zertifikat in sieben Tagen ist eine E-Mail. Eine tote Checkout-Seite ist ein Anruf.

Wer im Team arbeitet, braucht außerdem eine klare Zuständigkeit. Nichts ist so zuverlässig wie zwei Admins, die beide denken, der andere kümmert sich. Über Benachrichtigungsgruppen lässt sich das an den Checks festmachen statt im Kopf.

Eine Statusseite spart dir den Support-Vormittag

Wenn eine bekannte Seite ausfällt, kommen die Meldungen parallel: E-Mail, Telefon, Chat, alle mit derselben Frage. Eine öffentliche Statusseite, die unabhängig von der eigentlichen Infrastruktur erreichbar ist, nimmt diesen Druck weg. Du schreibst einmal, was los ist, und arbeitest weiter.

Wichtig ist nur, dass die Statusseite nicht auf demselben Server liegt wie die Seite, über die sie informiert. Sonst ist sie genau dann weg, wenn sie gebraucht wird. Klingt banal. Passiert trotzdem regelmäßig.

Wie eine sinnvolle Einrichtung aussieht

Fang mit der Startseite und einer nicht gecachten Route an, beides mit Keyword-Prüfung. Ergänze SSL und DNS. Setz einen Schwellwert für die Antwortzeit, orientiert an dem, was deine Seite heute normal braucht, plus etwas Luft. Danach schaust du zwei Wochen zu, welche Alarme kommen, und schraubst an den Schwellwerten, statt sie zu deaktivieren.

Uptime Alien deckt genau diese Checks ab, von HTTP mit Inhaltsprüfung über SSL, DNS und TCP bis zu API-Endpunkten, mit Servern in Deutschland und einer Datenverarbeitung nach DSGVO. Wenn du sehen willst, wie das für deine WordPress-Installation aussieht, richte einen Check ein und lass ihn eine Woche laufen. Die interessanten Erkenntnisse kommen meist nicht aus den Ausfällen, sondern aus den Antwortzeiten.