WordPress-Überwachung

Überwachen Sie jede WordPress-Website, die Sie betreuen

Auf der Website wird nichts installiert. Uptimepage prüft jede WordPress-Website von außen, auf einer Seite, für die ihr Cache nicht einspringen kann, und meldet sich in Slack oder per E-Mail, wenn etwas sie lahmlegt, meist bevor der Inhaber der Website es bemerkt hat.

Kostenlos starten

Prüfen Sie eine Seite, für die der Cache nicht einspringen kann

Die meisten WordPress-Websites haben einen Seitencache vor PHP, durch ein Plugin, den Hoster oder ein CDN. Das ist gut für Besucher und schlecht für die Überwachung: Der Cache kann die Startseite weiter ausliefern, während PHP abgestürzt und die Datenbank nicht erreichbar ist, sodass ein Check auf der Startseite den ganzen Ausfall über grün bleibt. Behalten Sie den Check auf der Startseite, denn sie ist das, was Besucher sehen, und fügen Sie einen auf einer Seite hinzu, die der Cache auslässt, etwa /wp-json/, den Index der REST API. Sie kann ohne PHP und Datenbank nicht antworten, und wenn sie ausfällt, ist WordPress ausgefallen. Sperrt ein Sicherheits-Plugin die REST API für Besucher, antwortet sie mit 401 oder 403, was trotzdem beweist, dass PHP und Datenbank funktionieren; stellen Sie den Check dann so ein, dass er diesen Code erwartet. Manche Cache-Plugins und Hoster cachen auch diese Seite. Ist das bei Ihnen so, nehmen Sie eine andere Seite, die Ihr Cache ausnimmt.

Ein 200 beweist nicht, dass es Ihre Website ist

Eine leere Seite kann mit 200 zurückkommen. Ebenso die Parkseite, die ein Registrar nach einer verpassten Verlängerung schaltet, oder eine gehackte Website, die auf eine fremde weiterleitet. Geben Sie dem Check einen Text mit, den nur Ihre echte Seite enthält, etwa den Namen der Website in der Fußzeile, und eine Antwort ohne diesen Text gilt als Ausfall, egal mit welchem Statuscode.

Updates laufen, wenn Sie nicht hinsehen

Seit WordPress 5.5 können sich Plugins und Themes selbst aktualisieren, und Hintergrund-Updates laufen zweimal am Tag, ob jemand zusieht oder nicht. Seit 6.6 nimmt WordPress ein Plugin-Update zurück, das einen fatalen Fehler auslöst. Ein Update, das eine Seite ohne fatalen Fehler kaputt macht, bleibt live, und dann sind es der Inhalts-Check oder ein Browser-Flow, die es bemerken. Bei einem Monitor, der aus mehreren Regionen geprüft wird, alarmiert ein Aussetzer, den nur eine einzige Region sieht, standardmäßig niemanden, sodass sich der Alarm, den Sie bekommen, auf die Website bezieht und nicht auf einen schlechten Netzwerkpfad. Wenn Sie von Hand aktualisieren, planen Sie vorher ein Wartungsfenster, und die Alarme für diese Website ruhen, bis es endet.

Ein Shop, der lädt, aber nicht verkaufen kann

In einem WooCommerce-Shop können Startseite und Produktseiten problemlos laden, während ein Update, ein Zahlungs-Plugin oder eine Theme-Änderung den Warenkorb oder die Kasse kaputt gemacht hat. Ein Browser-Flow-Check geht den Weg, den ein Käufer geht, bis zu alle fünf Minuten: Er öffnet ein Produkt, legt es in den Warenkorb, geht zur Kasse und prüft, ob der Button „Place order“ (Bestellung aufgeben) da ist. Wählen Sie ein Produkt mit ausgeschalteter Lagerverwaltung, denn der Block-Checkout reserviert den Bestand im Warenkorb bei jedem Laden für einige Minuten. Scheitert ein Schritt, nennt das Ergebnis diesen Schritt, sodass Sie wissen, dass es die Kasse ist und nicht die ganze Website. Wie viele Flow-Checks Sie bekommen, hängt vom Tarif ab.

WP-Cron wartet auf Besucher

Geplante Beiträge, Backup-Plugins und die Hintergrundjobs von WooCommerce warten alle auf WP-Cron, und WP-Cron startet nur, wenn ein Besuch WordPress lädt. Besuche, die der Seitencache beantwortet, laden es nie, also läuft WP-Cron auf einer gecachten Website nur bei den Besuchen, die am Cache vorbeigehen. Websites, die es mit DISABLE_WP_CRON abschalten, verlassen sich stattdessen auf einen System-Cron, und diese Zeile geht bei einem Serverumzug leicht verloren. So oder so meldet sich kein Fehler. Das erste Anzeichen ist ein Beitrag mit dem Hinweis „Missed schedule“ (verpasster Zeitplan) oder ein Backup-Ordner, der seit Wochen nicht mehr wächst. Ein Heartbeat-Check macht aus dieser Stille einen Alarm: Lassen Sie WP-Cron vom System-Cron ausführen, pingen Sie danach die Heartbeat-URL, und wenn die Pings ausbleiben, erfahren Sie es.

Zertifikate und Domains laufen leise ab

Die Erneuerung über Let's Encrypt bricht gern nach einer DNS-Änderung oder einem Serverumzug, und niemand merkt es, bis Browser eine Warnung zeigen. Domains von Kunden liegen oft im eigenen Registrar-Konto des Kunden, bezahlt mit einer Karte, die letztes Jahr abgelaufen ist. Ein TLS-Check warnt, bevor das Zertifikat abläuft. Setzen Sie die Warnschwelle ein paar Tage unter den Punkt, an dem Ihre Erneuerung greift, damit eine normale Erneuerung still bleibt und Sie nur eine fehlgeschlagene erreicht. Ein Domain-Ablauf-Check warnt 30 Tage, bevor die Registrierung endet, und das lässt Zeit, den Kunden anzurufen.

Statusseiten, die Ihre Kunden öffnen können

Ein Kunde kann eine Statusseite mit eigener Marke bekommen, auf der nur seine eigenen Websites stehen. Störungen erscheinen dort, sobald Checks fehlschlagen, und wenn ein Kunde fragt, was letzte Nacht passiert ist, schicken Sie einen Link.

Eine Kundenliste ohne ein Formular pro Website

Für die ersten paar Websites reicht das Formular. Für eine ganze Kundenliste legen der Terraform-Provider, die REST API und der MCP-Server die Monitore in einem Durchgang an, mit denselben Checks und Alarmkanälen auf jedem, und mit Terraform liegt die Liste in einer Datei, die Sie prüfen können.

Eine Crontab für den Benutzer, dem die Website gehört. Setzen Sie die Heartbeat-Periode auf das Cron-Intervall, hier 5 Minuten, mit 5 Minuten Kulanzzeit

# Zuerst in wp-config.php ergänzen: define( 'DISABLE_WP_CRON', true );
# Als Benutzer der Website ausführen, nicht als root: WP-CLI läuft nicht als root.
URL=https://app.uptimepage.dev/ping/your-token
*/5 * * * * cd /var/www/example.com && /usr/local/bin/wp cron event run --due-now --quiet; curl -fsS -o /dev/null "$URL/$?"

# Shared Hosting ohne WP-CLI: Tragen Sie stattdessen dies in das Cron-Feld des Hosters ein,
# im kürzesten Intervall, das der Hoster erlaubt, und passen Sie die Heartbeat-Periode daran an.
# curl -fsS -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron" && curl -fsS -o /dev/null https://app.uptimepage.dev/ping/your-token

Häufige Fragen

Wie überwache ich eine WordPress-Website?

Legen Sie zwei HTTP-Checks an: einen auf der Startseite und einen auf einer Seite, die der Cache auslässt, etwa /wp-json/, den Index der REST API. Die Startseite zeigt, was Besucher bekommen, und die ungecachte Seite zeigt, ob PHP und Datenbank hinter dem Cache noch funktionieren. Ergänzen Sie TLS- und Domain-Ablauf-Checks sowie einen Heartbeat für WP-Cron. Auf der Website wird nichts installiert.

Muss ich ein WordPress-Plugin installieren?

Nein. Jeder Check läuft von den Sonden von Uptimepage gegen die öffentliche Website, also kommt nichts zu WordPress hinzu, und nichts hört auf zu melden, wenn WordPress kaputtgeht. Die einzigen Änderungen, die Sie eventuell vornehmen, sind auf dem Server: eine Cron-Zeile und eine Zeile in wp-config.php, falls Sie WP-Cron mit einem Heartbeat überwachen möchten.

Machen Checks alle 60 Sekunden die Website langsamer?

Nein. Ein Check lädt das HTML einer Seite, ohne Bilder, Skripte oder Styles, einmal pro Minute aus jeder Prüfregion. Selbst auf der ungecachten Seite, wo jeder Check PHP ausführt, liegt das weit unter dem normalen Traffic einer Live-Website. HTTP-Checks führen kein JavaScript aus und erscheinen daher nicht in Google Analytics. Ein Browser-Flow führt die Skripte der Seite aus wie ein Besucher, deshalb können seine Läufe dort auftauchen.

Ein Sicherheits-Plugin oder eine Firewall blockiert die Checks. Was nun?

Für HTTP-Checks lassen Sie Anfragen anhand des User-Agents durch: Erlauben Sie Anfragen, deren User-Agent uptimepage/ enthält. Beschränken Sie die Ausnahme auf die URLs, die Sie überwachen, denn diesen Header kann jeder senden. Die IP-Adressen der Sonden können sich ohne Ankündigung ändern, eine IP-Allowlist wird also irgendwann brechen. Browser-Flows senden einen anderen User-Agent und schicken Formulare ab, deshalb deckt eine für HTTP-Checks geschriebene Regel sie nicht ab. Mehr Details stehen auf der Bot-Seite, die unten verlinkt ist.

Kann es eine WooCommerce-Kasse überwachen?

Ja, mit einem Browser-Flow-Check, der ein Produkt in den Warenkorb legt und die Kasse öffnet. Er stoppt vor der Zahlung, nimmt also kein Geld ein und löst keine Bestell-E-Mails aus.

Kann ein Kunde eine eigene Statusseite bekommen?

Ja. Eine Statusseite zeigt nur die Monitore, die Sie darauf platzieren, also sieht ein Kunde seine eigenen Websites und sonst nichts, mit seinem Logo und seinen Farben. Wie viele Statusseiten Sie haben können, hängt vom Tarif ab.

Auf einen Blick

Plugin-Installation keine, Checks laufen von außen
Prüfintervall alle 60 s
Alarmkanäle E-Mail, Slack, Telegram, Webhooks + mehr
WP-Cron Heartbeat aus einem System-Cron
Ablaufwarnungen SSL-Zertifikat und Domain
Einstiegspreis kostenlos, ohne Karte

In unter 5 Minuten startklar.