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.

Do not simply increase the memory limit indefinitely #

When an application requires an unusual amount of memory, a higher limit may indeed be necessary—but it can also simply mask a symptom.

Examples of unusually high memory consumption can include:

• faulty plugin
• extremely large amount of data
• infinite loop
• problematic import
• inappropriate application configuration

Therefore, check the context of the error as well.

„Maximum execution time exceeded“ #

A message like:

Maximum execution time of ... seconds exceeded

means that a PHP process ran longer than allowed for this PHP environment.

This can be the case, for example, with:

• large imports
• complex exports
• slow external connections
• extensive database operations
• problematic application code

occur.

Here too, the limit should not be increased blindly. First check which process is affected.

Understanding a PHP Warning #

One:

PHP Warning

is fundamentally not the same as a fatal error.

PHP can continue processing with many warnings.

Nevertheless, warnings can indicate errors or outdated or problematic programming.

If the same warning occurs very frequently, it can also unnecessarily bloat log files.

PHP Notice and Deprecated messages #

Messages such as:

PHP Notice

or:

PHP Deprecated

must also be distinguished from a fatal error.

A deprecation notice typically indicates that code uses a function or practice that is considered outdated and may no longer be supported in the future.

Such messages frequently occur with older applications, plugins, or themes, for example, after switching to a newer PHP version.

Many deprecated messages after PHP upgrade #

If numerous deprecated messages appear immediately after a PHP change, you should check whether the application in question is fully compatible with the new PHP version.

You generally manage the PHP version of your domain at CURIAWEB via the MultiPHP Manager.

Do not randomly set multiple PHP versions one after another. First check the system requirements of the software being used.

Error message points to a WordPress plugin #

For example, a WordPress path can look like this:

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

The area:

/wp-content/plugins/example-plugin/

shows that the file belongs to a plugin.

If a fatal error is triggered there, this plugin is one of the first components you should investigate.

However, this does not automatically mean that the plugin alone is to blame. A conflict with another plugin, theme, PHP, or WordPress itself may also be involved.

Error message points to a WordPress theme #

A path like:

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

points out that the affected file is located within a theme.

Then check in particular:

• Has the theme just been updated?
• Has PHP been changed?
• Has WordPress been updated?
• Did the error occur immediately after a theme customization?
• Is it custom code?

Error message points to wp-content, but the cause may lie elsewhere #

In WordPress, the core, plugins, and themes are constantly interacting with each other.

An error can therefore, for example, become visible in Plugin A, even though a change caused by Plugin B triggered the problematic state.

Therefore, consider the file path as an important clue—not as automatic proof of guilt.

Understand Stack Trace #

In certain PHP errors, an additional so-called Stack Trace logged.

This shows in a simplified way which functions or files were called before the error occurred.

Schematically:

#0 File A → Function X
#1 File B → Function Y
#2 File C → Function Z
#3 Main Call

A stack trace can be very valuable because it shows the path up to the actual error.

When reading a stack trace, don't just read the last line #

A stack trace contains multiple involved calls.

Therefore, the first visible file or the last line is not automatically the cause.

For example, in WordPress, a plugin can call a WordPress core function where the error finally becomes visible.

For the diagnosis, the entire call chain is relevant.

„thrown in … on line …“ #

For PHP fatal errors, the end of a message might say, for example:

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

This information indicates the exact location where the exception or error was ultimately triggered.

Document this line along with the previous error text.

Missing file after plugin or theme update #

If messages about missing files occur immediately after an update, the update may be incomplete or an installation damaged.

In this case, do not randomly delete individual files.

Check first:

• which component is affected
• whether the update has been fully completed
• whether a current backup exists
• whether the component can be cleanly reinstalled or restored

HTTP 500 and Error Log #

In the event of a server-side problem, a browser might only show:

500 Internal Server Error

This message alone does not yet indicate what caused the error.

For example, the error log can contain a specific PHP fatal error, an incorrect configuration, or a permission error.

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

HTTP 403 and Error Log #

At a:

403 Forbidden

can the error log also provide clues – for example in connection with permissions or access restrictions.

However, a 403 can also be caused by other security layers.

We cover systematic troubleshooting under Fix 403 Forbidden.

HTTP 503 and error log #

One

503 Service Unavailable

can have different causes.

In addition to application issues, resources or temporarily unavailable services may also be relevant.

Further steps can be found at Fix 503 Service Unavailable.

.Detect .htaccess errors #

A faulty .htaccess-configuration can cause a website to no longer be processed correctly.

Depending on the error, the log may contain clues about an invalid directive or a disallowed configuration.

If the problem immediately after a change to .htaccess has started, you should check this change first.

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

„Invalid command after .htaccess modification #

A message may indicate, for example, that a directive is not recognized or is not permitted in this context.

If you shortly before code from a third-party guide in .htaccess you inserted, restore the previous state and check the directive used.

Attention: Do not add random Apache or PHP instructions to .htaccess one. Not every directive is permitted in every hosting and PHP configuration.

Do not set PHP values blindly via .htaccess #

With modern PHP configurations, old tutorials with directives like:

php_value ...
php_flag ...

be unsuitable and, under certain PHP handlers, even trigger an HTTP 500 error.

You manage PHP settings in CURIAWEB via the designated cPanel tools.

We explain the procedure under Change PHP settings in cPanel.

Differentiate between file not found and 404 #

Not every message about a file not found means your entire website is broken.

Websites regularly receive requests for non-existent resources.

These can be, for example:

• old URLs
• deleted images
• broken links
• Bot requests
• automated scans

Therefore, a single entry for a non-existent file is not automatically critical.

Properly classifying bot requests #

Publicly accessible websites are regularly visited automatically.

This allows bots to request URLs that have never existed on your website.

Examples can include unusual paths to administrative interfaces, scripts, or known vulnerabilities of other systems.

Such entries are not automatically an indication that the file in question was present on your hosting.

Important: A log entry can merely show that someone requested a particular URL. It does not automatically follow that the requested file exists or that your website has been compromised.

Recurring errors are more important than random single reports #

When prioritizing, you should pay attention to whether a message:

• appears on every page view
• occurred only once
• always concerns the same file
• coincides with a visible website issue
• occurs only since a specific change

A reproducible error message that occurs exactly when calling the broken page is usually much more relevant than a random older log entry.

Distinguish between cause and consequential error #

A single problem can trigger multiple further error messages.

For example:

required file missing
        ↓
class cannot be loaded
        ↓
function cannot be executed
        ↓
page crashes with a fatal error

If you only address the last message, the root cause may persist.

Therefore, in the case of multiple simultaneous messages, check which one was created first and how the messages are related.

What was changed immediately before the error? #

One of the most valuable questions in diagnosis is:

What changed immediately before the error first occurred?

Examples:

• WordPress is updating
• Plugin updated
• Theme updated
• PHP version changed
• PHP setting changed
• .htaccess edited
• Files moved
• Website migrated
• new plugin installed

The temporal connection is not definitive proof, but a very valuable starting point.

Undo only one change at a time #

If the error started after a specific change, you should ideally first check that exact change or carefully reverse it.

Do not change simultaneously:

PHP Version
.htaccess
File permissions
Plugins
Theme
PHP limits

Otherwise, it will hardly be possible to determine later which measure was relevant.

Error after PHP change #

If a website stops working immediately after changing the PHP version, check the error log for messages like:

• Fatal Errors
• missing functions
• missing classes
• Deprecated messages
• Issues with extensions

If the application is not compatible with the new PHP version, a controlled rollback to the previously working version can be a useful diagnostic step.

Error after changing PHP settings #

If the problem occurred immediately after a change in the MultiPHP INI Editor, you should check the last modified directive.

We cover the PHP configuration in detail under Change PHP settings in cPanel.

Error after changing file permissions #

If files or directories received different permissions immediately before the error, you should also consider this context.

Do not set the permissions indiscriminately to ever higher values, but instead establish a configuration appropriate for the respective file type.

Error after migration #

Following a website migration, error messages can indicate the following problems, for example:

• old absolute file paths
• missing files
• incompatible PHP version
• missing PHP extensions
• incomplete transfer
• deviating configuration

Absolute paths in particular can differ between two hosting systems.

Error after restoring a backup #

If errors occur after a restoration, you should check whether the files and database belong to the same state.

An application can cause problems if, for example, newer files are combined with a significantly older database.

Distinguish between cPanel Error Log and WordPress Debug Log #

WordPress also has its own debugging features.

When WordPress debugging is enabled, for example, a file such as:

wp-content/debug.log

be used.

The WordPress debug log and the cPanel error log are not the same.

They can complement each other because they can log errors at different levels or with different contexts.

We cover the WordPress diagnosis under Using WordPress debugging and error logs.

Do not leave WordPress debugging permanently active unnecessarily #

Debugging features should be used selectively for diagnostics on a production website.

In particular, error messages should not be unnecessarily exposed publicly in the frontend.

Logs can contain technical information and should not be made publicly accessible.

Differentiate between cPanel Error Log and Cron Job output #

A PHP script that is executed via a cron job or the command line does not necessarily have to leave its errors in the same web server log.

Therefore, in case of cron job issues, you should also check the actual cron output and application-specific logs.

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

Difference between Error Log and Access Log #

An error log records errors or relevant error situations.

An access log, on the other hand, records requests made to the web server.

Simplified:

Access Log
→ Who or what accessed which resource?

Error Log
→ Which error occurred during processing?

Both log types can complement each other during a detailed diagnosis.

Raw access data in cPanel #

In the field of Measurements cPanel additionally provides features for access and statistical data.

For example, if you want to check whether a specific URL was accessed, access logs might be more helpful than the error log alone.

Differentiate error log and CloudLinux resources #

A slow or failed page load does not necessarily have to generate a classic PHP error.

If hosting resources are exhausted, you should additionally check the CloudLinux resource usage.

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

When resources and error log are interesting together #

Assuming a website fails sporadically and the error log contains no clear recurring PHP cause.

Then a comparison can be useful:

Time of website issue
↓
Check error log
↓
Check CloudLinux resources for the same time period

This can be used, for example, to determine whether the error coincides with a peak load.

Do not confuse old mistakes with current problems #

An error log can contain messages whose cause has long since been resolved.

For example, if a plugin caused a fatal error yesterday and is working correctly again today, the old message initially remains as a historical note.

Therefore, the temporal connection to the current problem is always decisive.

Trigger error deliberately again #

For a reproducible problem, the following approach is particularly effective:

1. Quickly check the cPanel Error Log.
2. Note the current time.
3. Access the affected page or feature exactly once.
4. Reopen or refresh the error log.
5. Search for new entries at the appropriate time.
6. Check the file path and error text.

This reduces the probability of analyzing a completely different log entry.

Error occurs only with a specific URL #

If only a single page is affected, check:

• which code specifically runs on this page
• which plugin or theme is involved
• whether the site uses special features
• whether a new log entry is created immediately upon calling

A working homepage does not prove that all PHP functions of the website are error-free.

Error only occurs in the WordPress admin area #

If the frontend works, but a specific administration page produces a fatal error for example, you should access this exact admin area and then check the new log entries.

Plugins can, for example, execute code only within the administration area.

Error only occurs with forms #

A form can work when the page is displayed normally and only generate an error when submitted.

Therefore, precisely reproduce the action where the problem occurs.

When troubleshooting, it's not just the URL that matters, but the specific sequence of events.

Error occurs only sporadically #

Sporadic errors are more difficult to diagnose.

Document as much as possible:

• Date and time
• affected URL
• executed action
• visible browser message
• simultaneous log entries
• potential resource values

The more precisely the time is known, the easier it is to compare different diagnostic sources with each other.

Do not share error messages publicly #

Error logs may contain internal file paths, usernames, technical configurations, or other information about the hosting environment.

Therefore, do not publish complete logs thoughtlessly in public forums or social networks.

Safety Notice: Check log extracts for passwords, tokens, API keys, personally identifiable information, and other confidential information before sharing them.

Do not send huge, incomplete logs #

For a support request, a relevant excerpt around the specific error is often more helpful than thousands of disconnected log lines.

Important are:

• Time
• complete error message
• affected file
• stack trace if applicable
• Description of the action that triggers the error

Copy error message completely #

When dealing with a technical report, do not just extract a single term.

For example, instead of just:

Fatal error

to pass on, the relevant message should be documented with error text, file path, and line number.

Precisely these details distinguish two completely different causes from each other.

Typical messages and initial troubleshooting steps #

Message	First test step
PHP Fatal error	check full error text, file, and line
Uncaught Error	Analyze error message and stack trace
Call to undefined function	Check PHP extension, application, and PHP version
Class ... not found	check affected application and missing dependency
Failed opening required	Check file path and existing files
No such file or directory	Check path, file name, and migration
Permission denied	Check file and directory permissions
Allowed memory size ... exhausted	Check memory requirements and PHP memory limit
Maximum execution time ... exceeded	check affected process and runtime
PHP Deprecated	Check software compatibility with PHP version
Invalid command	Check configuration or .htaccess

Systematic Troubleshooting with the cPanel Error Log #

1. Note the visible problem and the affected URL.
2. Record the current time.
3. Open Measured values → Errors.
4. Open the problematic page or function again.
5. Check for new log entries immediately afterward.
6. Compare the timestamp to your test.
7. Check error type and full error text.
8. Check file path and, if applicable, line number.
9. Assign the file to an application, plugin, or theme.
10. Check what was changed immediately before the first occurrence of the error.
11. Do not make multiple configuration changes at the same time.
12. Test the same process again after making a targeted change.

If nothing appears in the error log #

If no new entry appears in the cPanel Error Log during a reproducible error, that does not automatically mean that no technical problem exists.

Depending on the situation, you should check other diagnostic sources.

This may include:

• application-specific logs
• WordPress Debug Log
• Cron job output
• Access logs
• CloudLinux resources
• Browser Developer Tools for Frontend Issues

The correct source of diagnosis depends on the level at which the error occurs.

When should you contact CURIAWEB support? #

If you have a reproducible website error, the error log contains a technical message, and you cannot clearly resolve the cause, document the case as precisely as possible.

For an analysis, the following information is particularly helpful:

• affected domain
• affected URL or function
• Date and exact time of the error
• visible error message in the browser
• complete relevant error log entry
• affected file and line number, if available
• what was changed immediately before the problem
• whether the error is reproducible
• used PHP version, if relevant

Do not transmit passwords, tokens, API keys, or other confidential credentials.

Summary #

The cPanel error log under Measured values → Errors is one of the most important diagnostic tools for server-side website issues. It can show you when an error occurred, which file was involved, and what technical message was generated.

Always analyze an entry in the context of timestamp, error text, file path, and, if applicable, line number. A single word like Fatal error is not sufficient for a reliable diagnosis.

Typical messages like Permission denied, Allowed memory size exhausted, Failed opening required or Call to undefined function point to different error classes and require correspondingly different measures.

In WordPress, the file path can often show whether a plugin or theme is involved in the error. However, this is an indication and not automatically proof that this component is the sole cause.

Reproduce an error as in a controlled a manner as possible and check the error log immediately afterwards. This allows you to assign current messages to the specific problem much more reliably.

If no matching message appears there, you should switch the diagnostic source. WordPress debug logs, cron job outputs, access logs, and CloudLinux resources provide information on other technical levels.

The most important rule is: Do not fix the first red error message on suspicion. Reproduce the error, temporally match the corresponding log entry, and then work based on the specific message.