Read cPanel Error Log and find website errors

When a website shows an error, the visible message in the browser is often just a symptom. The actual problem can be caused, for example, by PHP, an application, incorrect file paths, permissions, or a faulty server configuration.

In CURIAWEB-cPanel you will find under Measured values → Errors current entries from the web server's error log. These messages can provide crucial clues as to, when, where and why an error has occurred.

In this guide, we show you how to access the cPanel error log, read typical error messages, and derive the next logical steps for troubleshooting.

Important: An error message should not be searched for individual terms alone. Timestamps, file paths, line numbers, and error text belong together. Only the complete context often reveals which file or application is actually affected.

What is the cPanel Error Log? #

Web servers and applications log specific errors that occur during the processing of a website.

In the cPanel area Error Can you view recent entries from the web server error log?.

Such entries may contain, for example, references to:

• PHP error
• missing files
• invalid file paths
• Permission issues
• misconfigurations
• Problems with PHP scripts
• certain Apache/web server messages

The error log is therefore one of the most important tools when diagnosing a website that suddenly stops working correctly.

What the error log is not #

The cPanel error log is not a complete history of all events within your hosting account.

It also does not automatically show:

• every error of every application
• all WordPress errors
• all database errors
• all cron job outputs
• all accesses to your website

Depending on the type of error, other logs or diagnostic tools may be relevant.

Briefly explained: The error log is an important starting point – but not every technical problem has to be logged there.

1. Open cPanel Error Log #

Log in to your CURIAWEB cPanel.

Then open:

Measured values → Errors

cPanel shows you current entries from the error log there.

2. Reproduce error first #

If a specific error is reproducible, you should reload the affected page immediately before checking the log.

Example:

13:42
→ call up faulty page

13:43
→ cPanel → Metrics → open Errors

As a result, you can much more easily correlate current log entries with the error that has just occurred.

Practical Tip: Note the exact time you triggered the error. Especially on high-traffic websites, numerous different messages can occur within a short period of time.

3. Do not automatically assume the newest entry is the cause #

The most recent log entry does not necessarily have to do with your problem.

For example, a website can simultaneously be accessed by:

• visitors
• Search engines
• Bots
• Monitoring systems
• other applications

to be called.

Therefore, always check the affected path or the specified file in addition to the timestamp.

How is an error message structured? #

The exact structure depends on the type of error. However, a log entry can contain information like this:

Timestamp
Error type
Error text
File path
Line number
Further technical information

A schematic PHP example could look like this:

PHP Fatal error:
Uncaught Error: ...
in /home/CPANELUSER/public_html/example.php
on line 125

Several components are relevant for troubleshooting.

Timestamp #

The timestamp helps you determine whether the message was actually generated at the time you observed the problem.

A report from yesterday is usually not proof of an error you just triggered.

Type of error #

The error type provides a first indication of the severity and category of the problem.

Examples:

PHP Fatal error
PHP Warning
PHP Notice
Permission denied
File not found

These messages do not mean the same thing and should therefore be treated differently.

Error message #

The actual error text describes what went wrong during processing.

Examples can be:

Call to undefined function ...
Class ... not found
Failed opening required ...
Permission denied
Allowed memory size ... exhausted

The error text is often the most important part for technical classification.

File path #

The specified file path often indicates which file was involved in the error.

For example:

/home/CPANELUSER/public_html/wp-content/plugins/example/plugin.php

From such a path, it can already be seen that the affected file is located within a WordPress plugin.

Important: A file path shows where the error was triggered or detected. This does not necessarily mean that this exact file alone is the actual cause.

Line number #

PHP error messages can additionally contain a line number:

on line 125

This allows the relevant section within the file to be located.

The line number is particularly helpful for developers or when dealing with your own code. In the case of a third-party plugin or theme, you should not simply delete or modify the line of code in question.

Understanding PHP Fatal Errors #

One

PHP Fatal error

means that PHP could not continue the execution in question due to a fatal error.

This can lead, for example, to:

• a page does not load
• only a blank page appears
• WordPress is reporting a critical error
• an HTTP 500 error occurs

What is crucial is the text that follows PHP Fatal error follows.

„Understanding “Uncaught Error“ #

A message like:

Uncaught Error: ...

indicates that an error occurred during PHP execution that was not caught by the application.

For example, a required function or class may be missing.

The message should always be viewed together with the following file path and line number.

„Call to undefined function“ #

A message like:

Call to undefined function example()

means that PHP does not recognize a called function or that it is not available at the time of the call.

Possible causes can be:

• missing PHP extension
• unloadable application file
• incompatible code
• faulty plugin or theme
• Version conflict

If the function belongs to a PHP extension, the article Enabling and Managing PHP Extensions in cPanel help.

„Class not found“ #

A message like:

Class "Example" not found

means that an application wants to use a PHP class that is not available at that time.

This can be done, for example, by:

• missing files
• incomplete updates
• broken dependencies
• incompatible plugins
• faulty custom code

be caused.

On a WordPress website, the file path can often show which plugin or theme is involved.

„Failed opening required“ #

A message like:

Failed opening required '/pfad/datei.php'

indicates that PHP could not successfully load a required file.

Check in particular:

• does the file exist?
• Is the path correct?
• was the file moved or deleted?
• Was an update incomplete?
• Are the permissions correct?

With the cPanel File Manager Can you check the specified path?.

„No such file or directory“ #

A message like:

No such file or directory

basically means that an expected file or directory was not found under the specified path.

This can occur, for example, after a migration, a manual file move, or a faulty update.

„Permission denied“ #

A message like:

Permission denied

indicates that a required access was not possible due to the existing permissions.

In this case, check first:

• which file or directory is affected
• which access was attempted
• whether the existing file permissions are plausible

You can find the basics under How to correctly set file permissions 644 and 755 in cPanel.

Attention: Do not set file permissions globally to 777, just to make an error message disappear. That doesn't cleanly solve the root cause and can degrade the security of the website.

„Allowed memory size exhausted“ #

A common PHP error message is essentially:

Allowed memory size of ... bytes exhausted

In this case, PHP has reached the memory limit available for the process.

The message often additionally contains:

• the available storage limit
• the additionally requested amount of memory
• the affected file
• a line number

We explain how to classify PHP memory and other limits at Set PHP memory limit, upload size, and execution time.

Memory Limit nicht einfach unbegrenzt erhöhen #

Wenn eine Anwendung ungewöhnlich viel Speicher benötigt, kann ein höheres Limit zwar erforderlich sein – es kann aber auch lediglich ein Symptom verdecken.

Beispiele für einen ungewöhnlich hohen Speicherverbrauch können sein:

• fehlerhaftes Plugin
• extrem große Datenmenge
• Endlosschleife
• problematischer Import
• ungeeignete Anwendungskonfiguration

Prüfe deshalb auch den Kontext des Fehlers.

„Maximum execution time exceeded“ #

A message like:

Maximum execution time of ... seconds exceeded

bedeutet, dass ein PHP-Prozess länger gelaufen ist als für diese PHP-Umgebung erlaubt.

Das kann beispielsweise bei:

• großen Importen
• aufwendigen Exporten
• langsamen externen Verbindungen
• umfangreichen Datenbankoperationen
• problematischem Anwendungscode

occur.

Auch hier sollte das Limit nicht blind erhöht werden. Prüfe zuerst, welcher Prozess betroffen ist.

PHP Warning verstehen #

Eine:

PHP Warning

ist grundsätzlich nicht dasselbe wie ein Fatal Error.

PHP kann die Verarbeitung bei vielen Warnungen fortsetzen.

Trotzdem können Warnungen auf Fehler oder veraltete beziehungsweise problematische Programmierung hinweisen.

Wenn dieselbe Warning sehr häufig auftritt, kann sie außerdem Logdateien unnötig vergrößern.

PHP Notice und Deprecated-Meldungen #

Messages such as:

PHP Notice

or:

PHP Deprecated

sind ebenfalls von einem Fatal Error zu unterscheiden.

Eine Deprecated-Meldung weist typischerweise darauf hin, dass Code eine Funktion oder Vorgehensweise verwendet, die als veraltet gilt und künftig möglicherweise nicht mehr unterstützt wird.

Solche Meldungen treten beispielsweise nach einem Wechsel auf eine neuere PHP-Version häufiger bei älteren Anwendungen, Plugins oder Themes auf.

Viele Deprecated-Meldungen nach PHP-Wechsel #

Wenn unmittelbar nach einem PHP-Wechsel zahlreiche Deprecated-Meldungen erscheinen, solltest du prüfen, ob die betreffende Anwendung vollständig mit der neuen PHP-Version kompatibel ist.

Die PHP-Version deiner Domain verwaltest du bei CURIAWEB grundsätzlich über den MultiPHP Manager.

Stelle nicht wahllos mehrere PHP-Versionen nacheinander ein. Prüfe zuerst die Systemanforderungen der verwendeten Software.

Fehlermeldung zeigt auf ein WordPress-Plugin #

Ein WordPress-Pfad kann beispielsweise so aussehen:

/home/CPANELUSER/public_html/wp-content/plugins/example-plugin/file.php

Der Bereich:

/wp-content/plugins/example-plugin/

zeigt, dass die Datei zu einem Plugin gehört.

Wenn ein Fatal Error dort ausgelöst wird, gehört dieses Plugin zu den ersten Komponenten, die du untersuchen solltest.

Das bedeutet jedoch nicht automatisch, dass das Plugin allein schuld ist. Auch ein Konflikt mit einem anderen Plugin, Theme, PHP oder WordPress selbst kann beteiligt sein.

Fehlermeldung zeigt auf ein WordPress-Theme #

A path like:

/wp-content/themes/example-theme/...

weist darauf hin, dass sich die betroffene Datei innerhalb eines Themes befindet.

Then check in particular:

• wurde das Theme gerade aktualisiert?
• Has PHP been changed?
• Has WordPress been updated?
• trat der Fehler unmittelbar nach einer Theme-Anpassung auf?
• handelt es sich um individuellen Code?

Fehlermeldung zeigt auf wp-content, aber Ursache kann woanders liegen #

Bei WordPress greifen Core, Plugins und Themes ständig ineinander.

Ein Fehler kann deshalb beispielsweise in Plugin A sichtbar werden, obwohl eine von Plugin B verursachte Änderung den problematischen Zustand ausgelöst hat.

Betrachte den Dateipfad deshalb als wichtigen Hinweis – nicht als automatischen Schuldbeweis.

Stack Trace verstehen #

Bei bestimmten PHP-Fehlern wird zusätzlich ein sogenannter Stack Trace protokolliert.

Dieser zeigt vereinfacht, welche Funktionen beziehungsweise Dateien aufgerufen wurden, bevor der Fehler entstanden ist.

Schematisch:

#0 Datei A → Funktion X
#1 Datei B → Funktion Y
#2 Datei C → Funktion Z
#3 Hauptaufruf

Ein Stack Trace kann sehr wertvoll sein, weil er den Weg bis zum eigentlichen Fehler zeigt.

Bei einem Stack Trace nicht nur die letzte Zeile lesen #

Ein Stack Trace enthält mehrere beteiligte Aufrufe.

Die erste sichtbare Datei oder die letzte Zeile ist deshalb nicht automatisch die Ursache.

Bei WordPress kann beispielsweise ein Plugin eine WordPress-Core-Funktion aufrufen, in der der Fehler schließlich sichtbar wird.

Für die Diagnose ist die gesamte Aufrufkette relevant.

„thrown in … on line …“ #

Bei PHP-Fatal-Errors kann am Ende einer Meldung beispielsweise stehen:

thrown in /home/CPANELUSER/public_html/example.php on line 125

Diese Angabe zeigt, an welcher Stelle die Ausnahme beziehungsweise der Fehler letztlich ausgelöst wurde.

Dokumentiere diese Zeile zusammen mit dem vorhergehenden Fehlertext.

Fehlende Datei nach Plugin- oder Theme-Update #

Wenn unmittelbar nach einem Update Meldungen über fehlende Dateien auftreten, kann das Update unvollständig oder eine Installation beschädigt sein.

Lösche in diesem Fall nicht wahllos einzelne Dateien.

Check first:

• welche Komponente betroffen ist
• ob das Update vollständig abgeschlossen wurde
• ob eine aktuelle Sicherung vorhanden ist
• ob die Komponente sauber neu installiert beziehungsweise wiederhergestellt werden kann

HTTP 500 und Error Log #

Ein Browser zeigt bei einem serverseitigen Problem möglicherweise nur:

500 Internal Server Error

Diese Meldung allein sagt noch nicht, wodurch der Fehler verursacht wurde.

Das Error Log kann dazu beispielsweise einen konkreten PHP Fatal Error, eine fehlerhafte Konfiguration oder einen Berechtigungsfehler enthalten.

We cover the complete diagnosis under Fixing a 500 Internal Server Error.

HTTP 403 und Error Log #

Bei einem:

403 Forbidden

kann das Error Log ebenfalls Hinweise liefern – beispielsweise im Zusammenhang mit Berechtigungen oder Zugriffsbeschränkungen.

Ein 403 kann jedoch auch durch andere Sicherheitsebenen entstehen.

We cover systematic troubleshooting under Fix 403 Forbidden.

HTTP 503 und Error Log #

One

503 Service Unavailable

kann unterschiedliche Ursachen haben.

Neben Anwendungsproblemen können dabei auch Ressourcen oder vorübergehend nicht verfügbare Dienste relevant sein.

Further steps can be found at Fix 503 Service Unavailable.

.htaccess-Fehler erkennen #

A faulty .htaccess-Konfiguration kann dazu führen, dass eine Website nicht mehr korrekt verarbeitet wird.

Je nach Fehler kann das Protokoll Hinweise auf eine ungültige Direktive oder eine nicht erlaubte Konfiguration enthalten.

Wenn das Problem unmittelbar nach einer Änderung an .htaccess begonnen hat, solltest du diese Änderung zuerst prüfen.

You can find more information at .htaccess explained and safely edited.

„Invalid command“ nach .htaccess-Änderung #

Eine Meldung kann beispielsweise darauf hinweisen, dass eine Direktive nicht erkannt oder in diesem Kontext nicht erlaubt ist.

Wenn du kurz zuvor Code aus einer fremden Anleitung in .htaccess eingefügt hast, stelle den vorherigen Zustand wieder her und prüfe die verwendete Direktive.

Attention: Füge keine zufälligen Apache- oder PHP-Anweisungen in .htaccess ein. Nicht jede Direktive ist in jeder Hosting- und PHP-Konfiguration zulässig.

PHP-Werte nicht blind über .htaccess setzen #

Bei modernen PHP-Konfigurationen können alte Anleitungen mit Direktiven wie:

php_value ...
php_flag ...

ungeeignet sein und unter bestimmten PHP-Handlern sogar einen HTTP-500-Fehler auslösen.

PHP-Einstellungen verwaltest du bei CURIAWEB über die dafür vorgesehenen cPanel-Werkzeuge.

We explain the procedure under Change PHP settings in cPanel.

File not found und 404 unterscheiden #

Nicht jede Meldung über eine nicht gefundene Datei bedeutet, dass deine gesamte Website defekt ist.

Websites erhalten regelmäßig Anfragen nach nicht vorhandenen Ressourcen.

These can be, for example:

• alte URLs
• gelöschte Bilder
• fehlerhafte Links
• Bot-Anfragen
• automatisierte Scans

Ein einzelner Eintrag zu einer nicht vorhandenen Datei ist deshalb nicht automatisch kritisch.

Bot-Anfragen richtig einordnen #

Öffentlich erreichbare Websites werden regelmäßig automatisiert aufgerufen.

Dabei können Bots URLs anfordern, die auf deiner Website niemals existiert haben.

Beispiele können ungewöhnliche Pfade zu Administrationsoberflächen, Skripten oder bekannten Schwachstellen anderer Systeme sein.

Solche Einträge sind nicht automatisch ein Hinweis darauf, dass die betreffende Datei auf deinem Hosting vorhanden war.

Important: Ein Logeintrag kann lediglich zeigen, dass jemand eine bestimmte URL angefordert hat. Daraus folgt nicht automatisch, dass die angeforderte Datei existiert oder deine Website kompromittiert wurde.

Wiederkehrende Fehler sind wichtiger als zufällige Einzelmeldungen #

Bei der Priorisierung solltest du darauf achten, ob eine Meldung:

• bei jedem Seitenaufruf erscheint
• nur einmal aufgetreten ist
• immer dieselbe Datei betrifft
• mit einem sichtbaren Website-Problem zusammenfällt
• erst seit einer bestimmten Änderung auftritt

Eine reproduzierbare Fehlermeldung, die exakt beim Aufruf der defekten Seite entsteht, ist meist wesentlich relevanter als ein zufälliger älterer Logeintrag.

Ursache und Folgefehler unterscheiden #

Ein einzelnes Problem kann mehrere weitere Fehlermeldungen auslösen.

For example:

benötigte Datei fehlt
        ↓
Klasse kann nicht geladen werden
        ↓
Funktion kann nicht ausgeführt werden
        ↓
Seite bricht mit Fatal Error ab

Wenn du nur die letzte Meldung behandelst, kann die ursprüngliche Ursache bestehen bleiben.

Prüfe deshalb bei mehreren zeitgleichen Meldungen, welche zuerst entstanden ist und wie die Meldungen zusammenhängen.

Was wurde unmittelbar vor dem Fehler geändert? #

Eine der wertvollsten Fragen bei der Diagnose lautet:

Was hat sich unmittelbar vor dem ersten Auftreten des Fehlers geändert?

Examples:

• WordPress is updating
• Plugin updated
• Theme aktualisiert
• PHP-Version geändert
• PHP-Einstellung geändert
• .htaccess edited
• Files moved
• Website migrated
• neues Plugin installiert

Der zeitliche Zusammenhang ist kein endgültiger Beweis, aber ein sehr wertvoller Ausgangspunkt.

Immer nur eine Änderung zurücknehmen #

Wenn der Fehler nach einer konkreten Änderung begonnen hat, solltest du möglichst zuerst genau diese Änderung überprüfen beziehungsweise kontrolliert zurücknehmen.

Ändere nicht gleichzeitig:

PHP-Version
.htaccess
Dateiberechtigungen
Plugins
Theme
PHP-Limits

Sonst lässt sich später kaum noch feststellen, welche Maßnahme relevant war.

Fehler nach PHP-Wechsel #

Wenn eine Website unmittelbar nach einem PHP-Wechsel nicht mehr funktioniert, prüfe das Error Log auf Meldungen wie:

• Fatal Errors
• fehlende Funktionen
• fehlende Klassen
• Deprecated-Meldungen
• Probleme mit Erweiterungen

Wenn die Anwendung mit der neuen PHP-Version nicht kompatibel ist, kann ein kontrollierter Wechsel auf die zuvor funktionierende Version ein sinnvoller Diagnoseschritt sein.

Fehler nach Änderung der PHP-Einstellungen #

Wenn das Problem unmittelbar nach einer Änderung im MultiPHP INI Editor entstanden ist, solltest du die zuletzt geänderte Direktive prüfen.

Die PHP-Konfiguration behandeln wir ausführlich unter Change PHP settings in cPanel.

Fehler nach Änderung von Dateiberechtigungen #

Wenn Dateien oder Verzeichnisse unmittelbar vor dem Fehler andere Berechtigungen erhalten haben, solltest du auch diesen Zusammenhang berücksichtigen.

Setze die Rechte nicht wahllos auf immer höhere Werte, sondern stelle eine für den jeweiligen Dateityp geeignete Konfiguration her.

Fehler nach Migration #

Nach einem Website-Umzug können Fehlermeldungen beispielsweise auf folgende Probleme hinweisen:

• alte absolute Dateipfade
• missing files
• inkompatible PHP-Version
• fehlende PHP-Erweiterungen
• unvollständige Übertragung
• abweichende Konfiguration

Gerade absolute Pfade können sich zwischen zwei Hosting-Systemen unterscheiden.

Fehler nach Wiederherstellung eines Backups #

Wenn nach einer Wiederherstellung Fehler auftreten, solltest du prüfen, ob Dateien und Datenbank zum selben Stand gehören.

Eine Anwendung kann Probleme verursachen, wenn beispielsweise neuere Dateien mit einer deutlich älteren Datenbank kombiniert werden.

cPanel Error Log und WordPress Debug Log unterscheiden #

WordPress besitzt zusätzlich eigene Debugging-Möglichkeiten.

Bei aktiviertem WordPress-Debugging kann beispielsweise eine Datei wie:

wp-content/debug.log

be used.

Das WordPress Debug Log und das cPanel Error Log sind nicht dasselbe.

Sie können sich ergänzen, weil sie Fehler auf unterschiedlichen Ebenen beziehungsweise mit unterschiedlichem Kontext protokollieren können.

Die WordPress-Diagnose behandeln wir unter Using WordPress debugging and error logs.

WordPress Debugging nicht dauerhaft unnötig aktiv lassen #

Debugging-Funktionen sollten auf einer produktiven Website gezielt zur Diagnose verwendet werden.

Insbesondere Fehlermeldungen sollten nicht unnötig öffentlich im Frontend ausgegeben werden.

Logs können technische Informationen enthalten und sollten nicht öffentlich zugänglich gemacht werden.

cPanel Error Log und Cronjob-Ausgabe unterscheiden #

Ein PHP-Skript, das über einen Cronjob beziehungsweise die Kommandozeile ausgeführt wird, muss seine Fehler nicht zwangsläufig im gleichen Webserver-Log hinterlassen.

Bei Cronjob-Problemen solltest du deshalb zusätzlich die eigentliche Cron-Ausgabe und anwendungsspezifische Logs prüfen.

We explain the procedure under Cron job not working: Causes and solutions.

Error Log und Access Log unterscheiden #

Ein Error Log protokolliert Fehler beziehungsweise relevante Fehlersituationen.

Ein Access Log protokolliert dagegen Zugriffe auf den Webserver.

Simplified:

Access Log
→ Wer beziehungsweise was hat welche Ressource aufgerufen?

Error Log
→ Welcher Fehler ist bei der Verarbeitung aufgetreten?

Beide Logtypen können sich bei einer detaillierten Diagnose ergänzen.

Rohdaten von Zugriffen in cPanel #

In the field of Measurements stellt cPanel zusätzlich Funktionen für Zugriffs- und Statistikdaten bereit.

Wenn du beispielsweise untersuchen möchtest, ob eine bestimmte URL aufgerufen wurde, sind Zugriffsdaten unter Umständen hilfreicher als das Error Log allein.

Error Log und CloudLinux-Ressourcen unterscheiden #

Ein langsamer oder fehlgeschlagener Seitenaufruf muss nicht zwingend einen klassischen PHP-Fehler erzeugen.

Wenn Hosting-Ressourcen ausgeschöpft werden, solltest du zusätzlich die CloudLinux-Ressourcennutzung prüfen.

We explain how this works at Understanding CloudLinux Resource Usage in cPanel.

Wann Ressourcen und Error Log gemeinsam interessant sind #

Angenommen, eine Website fällt sporadisch aus und das Error Log enthält keine eindeutige wiederkehrende PHP-Ursache.

Dann kann ein Vergleich sinnvoll sein:

Zeitpunkt des Website-Problems
        ↓
Error Log prüfen
        ↓
CloudLinux-Ressourcen zum selben Zeitraum prüfen

Damit lässt sich beispielsweise erkennen, ob der Fehler mit einer Lastspitze zusammenfällt.

Alte Fehler nicht mit aktuellen Problemen verwechseln #

Ein Error Log kann Meldungen enthalten, deren Ursache längst behoben wurde.

Wenn beispielsweise gestern ein Plugin einen Fatal Error erzeugt hat und heute wieder korrekt funktioniert, bleibt die alte Meldung zunächst ein historischer Hinweis.

Entscheidend ist deshalb immer der zeitliche Zusammenhang mit dem aktuellen Problem.

Fehler gezielt erneut auslösen #

Bei einem reproduzierbaren Problem ist folgende Vorgehensweise besonders effektiv:

1. cPanel Error Log kurz kontrollieren.
2. Aktuelle Uhrzeit notieren.
3. Betroffene Seite oder Funktion genau einmal aufrufen.
4. Error Log erneut öffnen beziehungsweise aktualisieren.
5. Nach neuen Einträgen zum entsprechenden Zeitpunkt suchen.
6. Dateipfad und Fehlertext prüfen.

Damit reduzierst du die Wahrscheinlichkeit, einen völlig anderen Logeintrag zu analysieren.

Fehler tritt nur bei einer bestimmten URL auf #

Wenn nur eine einzelne Seite betroffen ist, prüfe:

• welcher Code speziell auf dieser Seite ausgeführt wird
• welches Plugin beziehungsweise Theme daran beteiligt ist
• ob die Seite besondere Funktionen verwendet
• ob unmittelbar beim Aufruf ein neuer Logeintrag entsteht

Eine funktionierende Startseite beweist nicht, dass sämtliche PHP-Funktionen der Website fehlerfrei sind.

Fehler tritt nur im WordPress-Adminbereich auf #

Wenn das Frontend funktioniert, aber beispielsweise eine bestimmte Verwaltungsseite einen Fatal Error erzeugt, solltest du genau diesen Adminbereich aufrufen und anschließend die neuen Logeinträge prüfen.

Plugins können beispielsweise Code nur innerhalb des Administrationsbereichs ausführen.

Fehler tritt nur bei Formularen auf #

Ein Formular kann beim normalen Anzeigen der Seite funktionieren und erst beim Absenden einen Fehler erzeugen.

Reproduziere deshalb genau die Aktion, bei der das Problem auftritt.

Bei der Fehlersuche zählt nicht nur die URL, sondern der konkrete Ablauf.

Error occurs only sporadically #

Sporadische Fehler sind schwieriger zu diagnostizieren.

Dokumentiere möglichst:

• Date and time
• betroffene URL
• ausgeführte Aktion
• sichtbare Browsermeldung
• gleichzeitige Logeinträge
• mögliche Ressourcenwerte

Je genauer der Zeitpunkt bekannt ist, desto leichter lassen sich verschiedene Diagnosequellen miteinander vergleichen.

Fehlermeldung nicht öffentlich weitergeben #

Error Logs können interne Dateipfade, Benutzernamen, technische Konfigurationen oder andere Informationen über die Hosting-Umgebung enthalten.

Veröffentliche vollständige Logs deshalb nicht unüberlegt in öffentlichen Foren oder sozialen Netzwerken.

Safety Notice: Prüfe Logauszüge vor dem Weitergeben auf Passwörter, Tokens, API-Schlüssel, personenbezogene Daten und andere vertrauliche Informationen.

Nicht komplette riesige Logs senden #

Für eine Supportanfrage ist ein relevanter Ausschnitt rund um den konkreten Fehler häufig hilfreicher als tausende unzusammenhängende Logzeilen.

Wichtig sind:

• Time
• vollständige Fehlermeldung
• betroffene Datei
• gegebenenfalls Stack Trace
• Beschreibung der Aktion, die den Fehler auslöst

Fehlermeldung vollständig kopieren #

Schneide bei einer technischen Meldung nicht nur einen einzelnen Begriff heraus.

For example, instead of just:

Fatal error

weiterzugeben, sollte die relevante Meldung mit Fehlertext, Dateipfad und Zeilennummer dokumentiert werden.

Gerade diese Details unterscheiden zwei völlig verschiedene Ursachen voneinander.

Typische Meldungen und erste Prüfschritte #

Meldung	Erster Prüfschritt
PHP Fatal error	vollständigen Fehlertext, Datei und Zeile prüfen
Uncaught Error	Fehlertext und Stack Trace auswerten
Call to undefined function	PHP-Erweiterung, Anwendung und PHP-Version prüfen
Class ... not found	betroffene Anwendung und fehlende Abhängigkeit prüfen
Failed opening required	Dateipfad und vorhandene Dateien prüfen
No such file or directory	Pfad, Dateiname und Migration prüfen
Permission denied	Datei- und Verzeichnisberechtigungen prüfen
Allowed memory size ... exhausted	Speicherbedarf und PHP Memory Limit prüfen
Maximum execution time ... exceeded	betroffenen Prozess und Laufzeit prüfen
PHP Deprecated	Software-Kompatibilität mit PHP-Version prüfen
Invalid command	Konfiguration beziehungsweise .htaccess prüfen

Systematische Fehlersuche mit dem cPanel Error Log #

1. Notiere das sichtbare Problem und die betroffene URL.
2. Notiere die aktuelle Uhrzeit.
3. Open Measured values → Errors.
4. Rufe die problematische Seite beziehungsweise Funktion erneut auf.
5. Prüfe unmittelbar danach neue Logeinträge.
6. Vergleiche den Zeitstempel mit deinem Test.
7. Prüfe Fehlerart und vollständigen Fehlertext.
8. Prüfe Dateipfad und gegebenenfalls Zeilennummer.
9. Ordne die Datei einer Anwendung, einem Plugin oder Theme zu.
10. Prüfe, was unmittelbar vor dem ersten Auftreten des Fehlers geändert wurde.
11. Nimm nicht mehrere Konfigurationsänderungen gleichzeitig vor.
12. Teste nach einer gezielten Änderung erneut denselben Ablauf.

Wenn im Error Log nichts erscheint #

Wenn beim reproduzierbaren Fehler kein neuer Eintrag im cPanel Error Log erscheint, bedeutet das nicht automatisch, dass kein technisches Problem existiert.

Je nach Situation solltest du andere Diagnosequellen prüfen.

This may include:

• anwendungseigene Logs
• WordPress Debug Log
• Cronjob-Ausgabe
• Zugriffslogs
• CloudLinux resources
• Browser-Entwicklerwerkzeuge bei Frontend-Problemen

Die richtige Diagnosequelle hängt davon ab, auf welcher Ebene der Fehler entsteht.

When should you contact CURIAWEB support? #

Wenn du einen reproduzierbaren Website-Fehler hast, das Error Log eine technische Meldung enthält und du die Ursache nicht eindeutig beheben kannst, dokumentiere den Fall möglichst präzise.

For an analysis, the following information is particularly helpful:

• affected domain
• betroffene URL beziehungsweise Funktion
• Datum und genaue Uhrzeit des Fehlers
• sichtbare Fehlermeldung im Browser
• vollständiger relevanter Error-Log-Eintrag
• betroffene Datei und Zeilennummer, falls vorhanden
• was unmittelbar vor dem Problem geändert wurde
• whether the error is reproducible
• verwendete PHP-Version, falls relevant

Übermittle keine Passwörter, Tokens, API-Schlüssel oder andere vertrauliche Zugangsdaten.

Summary #

Das cPanel Error Log unter Measured values → Errors ist eines der wichtigsten Diagnosewerkzeuge bei serverseitigen Website-Problemen. Es kann dir zeigen, wann ein Fehler aufgetreten ist, welche Datei beteiligt war und welche technische Meldung erzeugt wurde.

Analysiere einen Eintrag immer im Zusammenhang mit Zeitstempel, Fehlertext, Dateipfad und gegebenenfalls Zeilennummer. Ein einzelnes Wort wie Fatal error reicht für eine zuverlässige Diagnose nicht aus.

Typische Meldungen wie Permission denied, Allowed memory size exhausted, Failed opening required or Call to undefined function weisen auf unterschiedliche Fehlerklassen hin und erfordern entsprechend unterschiedliche Maßnahmen.

Bei WordPress kann der Dateipfad häufig zeigen, ob ein Plugin oder Theme am Fehler beteiligt ist. Das ist jedoch ein Hinweis und nicht automatisch der Beweis, dass diese Komponente allein die Ursache darstellt.

Reproduziere einen Fehler möglichst kontrolliert und kontrolliere unmittelbar danach das Error Log. Dadurch kannst du aktuelle Meldungen wesentlich zuverlässiger dem konkreten Problem zuordnen.

Wenn dort keine passende Meldung erscheint, solltest du die Diagnosequelle wechseln. WordPress Debug Logs, Cronjob-Ausgaben, Zugriffslogs und CloudLinux-Ressourcen liefern Informationen über andere technische Ebenen.

The most important rule is: Nicht die erste rote Fehlermeldung auf Verdacht reparieren. Reproduziere den Fehler, ordne den passenden Logeintrag zeitlich zu und arbeite anschließend anhand der konkreten Meldung.