Wenn deine Website langsam ist, zeitweise nicht erreichbar war oder im WordPress Backend Fehler auftreten, können die Logs deiner Box wichtige Hinweise auf die Ursache liefern.
Dabei ist wichtig: Ein Logeintrag beschreibt zunächst nur, was zu einem bestimmten Zeitpunkt passiert ist. Er nennt nicht automatisch die eigentliche Ursache eines Problems.
Ein Fehler im Log kann zum Beispiel durch ein Plugin, Theme, einen PHP Prozess, einen ungewöhnlich aufwendigen Request oder viele gleichzeitige Anfragen ausgelöst worden sein.
In diesem Artikel zeigen wir dir, wie du die Logs deiner Box liest, relevante Einträge erkennst und daraus sinnvolle nächste Schritte für die Fehlersuche ableitest.
💡 Du musst kein Server Profi sein
Viele Informationen in Logs sind technisch. Für eine erste Analyse musst du jedoch nicht jeden Bestandteil eines Logeintrags verstehen.
Häufig reichen bereits drei Fragen:
Wann ist das Problem aufgetreten?
Welche URL oder Funktion war betroffen?
Welche Einträge erscheinen zu diesem Zeitpunkt in den Logs?
Welche Logs gibt es?
Für die Fehlersuche sind insbesondere drei Arten von Logs relevant:
Log | Was wird protokolliert? | Besonders hilfreich bei |
Access Log | Zugriffe und Requests auf deine Website | Hoher Traffic, Bots, bestimmte URLs, 403/404/500/503 Fehler |
Error Log | Fehler bei der Verarbeitung von Requests | PHP Fehler, Plugin- oder Theme-Fehler, FastCGI Fehler |
Cron Log | Ausführung geplanter WordPress Aufgaben | Fehlende oder fehlerhafte Cronjobs, geplante Prozesse |
Die Logs ergänzen sich gegenseitig. Für eine gute Analyse solltest du deshalb häufig Access Log und Error Log für denselben Zeitraum vergleichen.
Wo finde ich die Logs meiner Box?
Aktuelle Logs kannst du direkt über das Raidboxes Dashboard einsehen.
Für eine ausführlichere Analyse stehen dir die Logs außerdem über SFTP beziehungsweise SSH im Verzeichnis "Logs" zur Verfügung.
Dort findest du die Logdateien der vergangenen sieben Tage.
Das ist besonders hilfreich, wenn ein Problem nicht mehr aktuell auftritt und du einen bestimmten Zeitpunkt in der Vergangenheit untersuchen möchtest.
Bevor du die Logs analysierst: Grenze das Problem ein
Bevor du nach Fehlermeldungen suchst, solltest du möglichst genau bestimmen, was eigentlich passiert ist.
Notiere dir idealerweise:
Wann trat das Problem auf? Datum & Uhrzeit.
Wie lange bestand es?
Trat es einmalig oder wiederholt auf?
War das Frontend betroffen?
War
/wp-admin/betroffen?Waren Frontend und Backend betroffen?
War nur eine bestimmte Seite oder Funktion betroffen?
Welche Aktion wurde unmittelbar vorher durchgeführt?
Trat der Fehler nach einem Plugin- oder Theme-Update auf?
Wurde gerade ein Import, Backup, WooCommerce Prozess oder anderer aufwendiger Vorgang ausgeführt?
Verschwand das Problem von selbst oder erst nach einer Änderung?
🔎 Je genauer du den Zeitraum kennst, desto einfacher wird die Log Analyse.
Statt mehrere Stunden Logs nach Auffälligkeiten zu durchsuchen, kannst du beispielsweise gezielt die Minuten rund um 14:32 Uhr untersuchen.
Access Logs verstehen
Das Access Log zeichnet Requests auf, die deine Website erreichen.
Ein vereinfachter Eintrag kann beispielsweise so aussehen:
203.0.113.42 - - [17/Aug/2026:14:32:15 +0200] "POST /wp-admin/admin-ajax.php HTTP/1.1" 503 441
Für die erste Analyse sind vor allem diese Informationen interessant
Die IP Adresse, von der der Request kam:
203.0.113.42
Zeitpunkt des Requests:
17/Aug/2026:14:32:15
HTTP Methode des Requests:
POST
Aufgerufene URL beziehungsweise Ressource:
/wp-admin/admin-ajax.php
HTTP Statuscode der Antwort:
503
Welche Statuscodes sind interessant?
Nicht jeder Statuscode ist ein Fehler.
Einige häufige Beispiele:
Statuscode | Bedeutung |
| Request wurde erfolgreich verarbeitet |
| Weiterleitung |
| Zugriff wurde abgelehnt |
| Ressource wurde nicht gefunden |
| Fehler bei der Verarbeitung |
| Fehler bei der Kommunikation mit einem Backend |
| Anfrage konnte zu diesem Zeitpunkt nicht erfolgreich vom Backend beantwortet werden |
| Zeitüberschreitung bei der Verarbeitung |
Einzelne Fehlercodes sind dabei nicht automatisch problematisch.
Wenn beispielsweise ein Bot eine nicht vorhandene URL aufruft und einen 404 erhält, funktioniert deine Website möglicherweise vollkommen normal.
Interessanter werden Muster und Häufungen.
⚠️ Ein 503 bedeutet nicht automatisch einen Serverausfall
Der Statuscode 503 Service Unavailable klingt zunächst so, als wäre der gesamte Server nicht erreichbar gewesen.
Das muss jedoch nicht der Fall sein.
Bei einer WordPress Website kann ein 503 beispielsweise auftreten, wenn ein einzelner Request nicht erfolgreich verarbeitet werden konnte.
Mögliche Zusammenhänge sind unter anderem:
ein sehr langsamer PHP Prozess
viele gleichzeitig laufende PHP Requests
ein Plugin mit aufwendigen Requests
WooCommerce Prozesse
AJAX Requests
REST API Requests
externe API Verbindungen
sehr viele gleichzeitige Zugriffe
Bots oder Crawler
ein Prozess, der nicht rechtzeitig antwortet
Deshalb solltest du bei einem 503 nicht nur nach dem Statuscode suchen, sondern untersuchen, welcher Request betroffen war und was zur gleichen Zeit passiert ist.
Beispiel: 503 auf admin-ajax.php
Im Access Log findest du beispielsweise wiederholt:
POST /wp-admin/admin-ajax.php HTTP/1.1" 503
Das sagt zunächst nur:
Requests an admin-ajax.php konnten zu diesem Zeitpunkt nicht erfolgreich verarbeitet werden.
admin-ajax.php wird von WordPress und vielen Plugins für Hintergrundanfragen verwendet.
Der Eintrag sagt deshalb noch nicht, welches Plugin oder welcher Prozess verantwortlich war.
Sinnvolle nächste Fragen:
Wie viele Requests an
admin-ajax.phpgab es in diesem Zeitraum?Waren die meisten erfolgreich (
200) oder schlugen viele mit503fehl?Trat das Problem nur für wenige Sekunden oder über mehrere Minuten auf?
Was wurde zu diesem Zeitpunkt im WordPress Backend ausgeführt?
Verwendet ein Plugin regelmäßig AJAX Requests?
Lief gerade ein Import, Export oder anderer aufwendiger Prozess?
Trat das Problem nach Installation oder Aktualisierung eines Plugins auf?
Gibt es zur gleichen Zeit passende Einträge im Error Log?
Damit wird aus einem Statuscode eine konkrete Fehlersuche.
Error Logs verstehen
Während das Access Log zeigt, welcher Request gestellt wurde und wie er beantwortet wurde, enthält das Error Log zusätzliche Informationen über Fehler während der Verarbeitung.
Ein typisches Beispiel kann etwa so aussehen:
AH01067: Failed to read FastCGI header
oder:
AH01075: Error dispatching request to
Solche Meldungen stammen aus der Kommunikation zwischen Webserver und PHP Verarbeitung.
Sie können beispielsweise auftreten, wenn ein PHP Prozess einen Request nicht wie erwartet abschließen konnte.
🧩 FastCGI Fehler sind häufig ein Symptom und noch keine Erklärung für die eigentliche Ursache.
FastCGI Fehler richtig untersuchen
Angenommen, du findest zur gleichen Zeit:
AH01067: Failed to read FastCGI header
und im Access Log:
POST /wp-admin/admin-ajax.php HTTP/1.1" 503
✅ Dann wissen wir bereits mehr:
Ein Request an
admin-ajax.phpwurde gestellt.Dieser Request erhielt einen 503.
Gleichzeitig gab es ein Problem bei der Kommunikation mit der PHP Verarbeitung.
❌ Was wir noch nicht wissen:
Warum konnte PHP den Request nicht erfolgreich abschließen?
Mögliche Ursachen können beispielsweise sein:
ein PHP Prozess läuft sehr lange
ein Plugin führt eine aufwendige Operation aus
viele PHP Requests laufen gleichzeitig
ein externer Dienst antwortet langsam
ein PHP Prozess wird unerwartet beendet
eine Datenbankabfrage benötigt ungewöhnlich lange
ein Import oder Hintergrundprozess belastet PHP
ein Request erreicht ein Timeout
Die nächste Frage sollte deshalb nicht nur lauten:
„Warum habe ich einen FastCGI Fehler?“
Sondern:
„Welcher Request hat den FastCGI Fehler ausgelöst und was hat WordPress zu diesem Zeitpunkt verarbeitet?“
PHP Fehler erkennen
Besonders hilfreich sind Fehlermeldungen, die bereits auf eine konkrete Datei zeigen.
Zum Beispiel:
PHP Fatal error: Uncaught Error ... in /wp-content/plugins/example-plugin/example.php
Hier liefert das Log einen wesentlich konkreteren Hinweis.
Der Fehler tritt innerhalb von:
/wp-content/plugins/example-plugin/
auf.
Damit sollte die weitere Fehlersuche zunächst beim entsprechenden Plugin beginnen.
Mögliche nächste Schritte sind beispielsweise:
Plugin aktualisieren
prüfen, ob der Fehler direkt nach einem Update begonnen hat
Plugin testweise deaktivieren
Kompatibilität mit der verwendeten PHP Version prüfen
Dokumentation des Plugins prüfen
Plugin Entwickler mit der vollständigen Fehlermeldung kontaktieren
Das Gleiche gilt entsprechend für Pfade innerhalb eines Themes:
/wp-content/themes/example-theme/
Fatal Error, Warning und Notice – was ist der Unterschied?
Nicht jede PHP Meldung hat die gleiche Bedeutung.
PHP Fatal error
PHP konnte den betreffenden Prozess aufgrund des Fehlers nicht fortsetzen.
Diese Meldungen sind bei konkreten Funktionsausfällen besonders relevant.
PHP Warning
PHP meldet ein Problem, konnte den Prozess jedoch möglicherweise weiter ausführen.
Eine Warning sollte untersucht werden, bedeutet aber nicht automatisch, dass sie den beobachteten Fehler verursacht hat.
PHP Notice
Hinweis auf ein mögliches Problem oder unsauberes Verhalten im Code.
⚠️ Zeitgleich bedeutet nicht automatisch ursächlich
Dass ein Eintrag zeitgleich mit deinem Problem im Log steht, beweist noch nicht, dass er dessen Ursache ist.
Zeitpunkte zwischen Access Log und Error Log vergleichen
Eine der wichtigsten Methoden bei der Log Analyse ist die zeitliche Korrelation.
Angenommen, ein Fehler trat um 14:32 Uhr auf.
Access Log
14:32:14 POST /wp-admin/admin-ajax.php 200
14:32:15 POST /wp-admin/admin-ajax.php 503
14:32:16 POST /wp-admin/admin-ajax.php 503
14:32:18 POST /wp-admin/admin-ajax.php 503
14:32:27 GET / 200
Error Log
14:32:15 AH01067: Failed to read FastCGI header
14:32:16 AH01075: Error dispatching request to ...
14:32:18 AH01067: Failed to read FastCGI header
Das Muster ist wesentlich aussagekräftiger als ein einzelner Eintrag.
Wir können daraus beispielsweise erkennen:
Die Website beantwortete weiterhin Requests.
Bestimmte Requests an
admin-ajax.phpschlugen fehl.Gleichzeitig gab es Probleme bei der PHP Verarbeitung.
Andere Requests wurden weiterhin mit
200beantwortet.
Das spricht gegen die einfache Schlussfolgerung:
„Der komplette Server war down.“
Die eigentliche Ursache muss nun innerhalb des betroffenen Prozesses weiter eingegrenzt werden.
Nicht nur Fehler suchen – erfolgreiche Requests sind ebenfalls wichtig
Bei einer Analyse solltest du nicht ausschließlich nach 500, 503 oder anderen Fehlercodes suchen.
💡Auch erfolgreiche Requests liefern wichtige Informationen.
Wenn beispielsweise während eines gemeldeten Ausfalls weiterhin viele Requests mit: 200 beantwortet wurden, kann das darauf hinweisen, dass nicht die gesamte Website betroffen war.
Vielleicht war nur:
eine bestimmte URL
das WordPress Backend
ein Formular
WooCommerce
eine AJAX Funktion
ein bestimmtes Plugin
betroffen.
Das hilft, die Ursache deutlich weiter einzugrenzen.
Wie lange trat der Fehler auf?
Ein weiterer wichtiger Faktor ist die Dauer.
Ein einzelner 503 um:
14:32:15
hat eine andere Bedeutung als hunderte 503 Antworten zwischen:
14:32
und:
15:10
Prüfe deshalb immer:
Wann erscheint der erste Fehler?
Wann erscheint der letzte Fehler?
Was passiert davor und danach?
Wenn unmittelbar davor und danach erfolgreiche Requests erscheinen, war möglicherweise nur ein einzelner Prozess betroffen.
Viele Requests können ebenfalls Probleme verursachen
Nicht jedes Performanceproblem entsteht durch einen einzelnen Fehler.
Auch die Anzahl der Requests kann entscheidend sein.
Beispiele sind:
Bots
Crawler
Brute Force Versuche
WooCommerce Filter
Suchfunktionen
admin-ajax.phpREST API Requests
externe Monitoring Dienste
fehlerhafte Plugins, die ungewöhnlich viele Requests erzeugen
Wenn dieselbe URL innerhalb kurzer Zeit sehr häufig aufgerufen wird, solltest du deshalb untersuchen:
Welche URL wird aufgerufen?
Von welchen IP Adressen kommen die Requests?
Handelt es sich immer um denselben User Agent?
Sind es GET oder POST Requests?
Wie viele Requests treten pro Minute auf?
Beginnen die Probleme gleichzeitig mit diesem Traffic?
🔎 Ein hohes Requestvolumen ist jedoch ebenfalls noch kein Beweis für die Ursache.
Es liefert zunächst einen Ansatzpunkt für die weitere Untersuchung.
Cron Logs verstehen
WordPress verwendet Cronjobs für geplante Aufgaben.
Dazu können beispielsweise gehören:
geplante Veröffentlichungen
WooCommerce Aufgaben
E-Mail Benachrichtigungen
Plugin Prozesse
Synchronisationen
Wartungsaufgaben
Wenn eine geplante Funktion nicht ausgeführt wird, lohnt sich deshalb ein Blick in die Cron Logs.
Dabei solltest du insbesondere prüfen:
Wird der betreffende Cronjob überhaupt gestartet?
Wann wurde er zuletzt ausgeführt?
Gibt es Fehlermeldungen zur gleichen Zeit?
Wird der Job ungewöhnlich häufig ausgeführt?
Dauert die Ausführung ungewöhnlich lange?
Gehört der Cronjob zu WordPress selbst oder zu einem Plugin?
Wenn der Cronjob zu einem Plugin gehört, kann anschließend die Plugin Dokumentation bei der weiteren Analyse helfen.
Performanceprobleme mit Logs untersuchen
💡 Logs können Hinweise auf Performanceprobleme liefern. Sie sind jedoch kein vollständiges Performance Monitoring.
Ein sinnvoller Ausgangspunkt ist deshalb immer eine konkrete Beobachtung.
Zum Beispiel:
„Das Speichern einer Seite im WordPress Backend dauerte am 17. August zwischen 10:15 und 10:20 Uhr ungefähr 40 Sekunden.“
Das ist wesentlich hilfreicher als:
„Meine Website ist manchmal langsam.“
Prüfe anschließend den betreffenden Zeitraum.
1. Welche Requests wurden ausgeführt?
Zum Beispiel:
POST /wp-admin/post.php
oder:
POST /wp-admin/admin-ajax.php
2. Gibt es Fehler?
Suche im gleichen Zeitraum im Error Log.
3. Gibt es ungewöhnlich viele Requests?
Prüfe, ob bestimmte URLs oder Prozesse sehr häufig aufgerufen werden.
4. Ist nur das Backend betroffen?
Wenn das Frontend schnell reagiert, während bestimmte Backend Aktionen langsam sind, deutet das auf ein anderes Problem hin als eine generell langsame Website.
5. Was wurde zu diesem Zeitpunkt ausgeführt?
Zum Beispiel:
Seite gespeichert
Plugin aktualisiert
WooCommerce Import gestartet
Cache geleert
Backup erstellt
Elementor geöffnet
externe Synchronisation gestartet
Diese Information kann entscheidender sein als der eigentliche Logeintrag.
Was Logs nicht beantworten können
Logs sind ein wichtiges Diagnosewerkzeug, aber sie liefern nicht automatisch eine vollständige Ursachenanalyse.
Ein Log kann beispielsweise zeigen:
POST /wp-admin/admin-ajax.php => 503
Das Log weiß jedoch nicht automatisch:
„Plugin X hat gerade Funktion Y ausgeführt, die aufgrund einer langsamen externen API 35 Sekunden benötigt hat.“
Dafür können weitere Werkzeuge notwendig sein, beispielsweise:
WordPress Debugging
Plugin Debug Logs
Browser Developer Tools
Query Monitor
Application Performance Monitoring
Datenbankanalyse
Analyse externer APIs
Plugin- oder Theme-Dokumentation
🛠️ Hostingproblem oder Websiteproblem?
Diese Unterscheidung ist bei der Fehlersuche besonders wichtig.
Raidboxes stellt die Hostingumgebung bereit und unterstützt dich bei Problemen, die diese Umgebung betreffen.
Die Analyse und Optimierung des Codes einer Website, einzelner Plugins, Themes, Datenbankabfragen oder individueller WordPress Funktionen gehört dagegen zur Entwicklung und Wartung der Website.
Unsere Logs sollen dir deshalb möglichst viele Informationen geben, mit denen du solche Probleme selbst oder gemeinsam mit deiner Agentur beziehungsweise deinem Webentwickler untersuchen kannst.
Wenn die Logs auf ein Problem innerhalb unserer Hostinginfrastruktur hindeuten oder die Ursache nicht sinnvoll auf Websiteebene eingegrenzt werden kann, schauen wir uns den Fall natürlich gerne mit dir an.
📋 Bevor du den Raidboxes Support kontaktierst
Wenn du ein technisches Problem nicht selbst eingrenzen kannst, helfen uns konkrete Informationen dabei, den Fall wesentlich schneller zu untersuchen.
Sende uns nach Möglichkeit:
die betroffene Box
Datum des Problems
möglichst genaue Uhrzeit
ungefähre Dauer
betroffene URL
Fehlermeldung beziehungsweise HTTP Statuscode
Information, ob Frontend, Backend oder beides betroffen war
Information, ob das Problem weiterhin besteht
welche Aktion unmittelbar vor dem Problem durchgeführt wurde
relevante Ausschnitte aus Access oder Error Log
Statt:
„Meine Website war heute wieder down.“
ist beispielsweise folgende Beschreibung wesentlich hilfreicher:
„Am 17. August zwischen ungefähr 14:32 und 14:35 Uhr konnte ich im WordPress Backend keine Seiten speichern. Das Frontend war weiterhin erreichbar. Beim Speichern erhielt ich einen 503. Im Access Log sehe ich in diesem Zeitraum mehrere 503 Antworten auf /wp-admin/admin-ajax.php. Gleichzeitig erscheinen im Error Log mehrere AH01067: Failed to read FastCGI header Meldungen.“
Damit können wir direkt beim relevanten Zeitraum und Request mit der Analyse beginnen.
✅ Kurz gesagt: So gehst du bei der Log Analyse vor
Wenn ein Problem auftritt, gehe am besten in dieser Reihenfolge vor:
1. Zeitpunkt bestimmen
Wann genau trat das Problem auf?
2. Problem eingrenzen
Frontend, Backend, einzelne URL oder bestimmte Funktion?
3. Access Log prüfen
Welche Requests wurden zu diesem Zeitpunkt gestellt und welche Statuscodes wurden zurückgegeben?
4. Error Log vergleichen
Gibt es zum gleichen Zeitpunkt passende Fehlermeldungen?
5. Muster suchen
Ein einzelner Fehler oder viele? Dieselbe URL? Dieselbe Aktion? Dieselbe IP?
6. Kontext berücksichtigen
Was passierte unmittelbar vorher? Update, Import, Plugin Aktion, hoher Traffic oder andere Änderung?
7. Ursache weiter eingrenzen
Zeigt der Fehler auf ein Plugin, Theme oder einen bestimmten Prozess, untersuche diesen als nächsten Schritt.
8. Nicht vorschnell Schlussfolgerungen ziehen
Ein 503, FastCGI Fehler oder PHP Warning allein beweist noch nicht die Ursache.
Logs werden besonders hilfreich, wenn du Zeitpunkt + Request + Fehlermeldung + Verhalten der Website miteinander verbindest.
📚 Weiterführende Artikel