Your site is broken, someone has asked you to “check the error log”, and you are now looking at a hosting dashboard wondering which of the five things labelled “logs” they meant. Or you have found a file called debug.log, opened it, and it is thousands of lines of text that all look equally alarming.
Both situations are normal. Error logs are written for machines and developers, not for site owners, but you do not need to be a developer to find the right one and pick out the line that matters. This guide covers where WordPress and your server keep their logs, how a typical entry is put together, and a method for finding the one entry that explains the problem.
The different logs, and which one you need
There is not one error log. There are usually three or four, written by different parts of the system. Knowing which layer failed tells you which log to open.
WordPress’s own log: debug.log
WordPress only writes this file if logging has been switched on in wp-config.php. By default it lives at wp-content/debug.log, though a developer may have pointed it somewhere else. If the file does not exist, logging is off; our guide to switching on WordPress debug mode explains how to enable it without showing errors to visitors. Check the WP_DEBUG_LOG line in wp-config.php if you suspect a custom location.
The PHP error log
PHP can log errors on its own, independent of WordPress. On many cPanel-style hosts this appears as a file named error_log in the site’s main folder, or in the folder where the error happened, such as wp-admin. Other hosts collect PHP errors in a central place shown in the control panel. This log catches problems that happen before WordPress has loaded far enough to write its own log.
The web server error log
Apache or Nginx keep their own error log. It records things like permission problems, broken rewrite rules, timeouts talking to PHP, and requests the server refused. On a self-managed Linux server it is commonly /var/log/apache2/error.log or /var/log/httpd/error_log for Apache, and /var/log/nginx/error.log for Nginx, though hosts vary. On shared hosting you reach it through the control panel instead.
The access log
This one does not record errors as such. It records every request: the address, the time, the visitor’s IP and the response code. It is useful for questions like “when did the 500 errors start?” or “is one IP hammering the login page?”, but it will not tell you why something failed.
Finding the logs in common hosting panels
- cPanel: look for an “Errors” tool under the Metrics section, which shows recent web server errors, and for
error_logfiles through File Manager. “Raw Access” gives you access logs. - Plesk: open the domain under Websites & Domains and look for “Logs”. It shows access and error entries together with a filter for errors.
- Managed WordPress hosts: most have a logs area in their own dashboard, often with separate PHP and server entries.
- No panel access: ask your host. A clear request works best: “Please send the PHP and web server error log entries for example.com between 10:00 and 10:30 today.”
Whatever the panel, download a copy before you start reading if the log is large. Viewing a huge file in a browser can be slow or cut off.
Anatomy of a log entry
Most entries you meet in debug.log or a PHP error log follow the same shape. Here is a made-up but typical one:
[14-Oct-2026 08:42:17 UTC] PHP Fatal error: Uncaught Error: Call to undefined function example_get_options() in /home/user/public_html/wp-content/plugins/example-plugin/includes/settings.php:57
Read it left to right:
- The timestamp in square brackets. Entries written by WordPress are normally in UTC rather than your local time, so a site in India will see times five and a half hours behind IST, and a site in London will match local time only in winter. Convert before you match an entry to “the moment it broke”.
- The severity: Fatal error, Warning, Notice, Deprecated or Parse error. Fatal and Parse errors stop the page.
- The description. “Call to undefined function”, “Allowed memory size exhausted”, “Class not found”, “Cannot redeclare” and similar phrases each point to a different kind of fault.
- The file path. This is usually the most useful part. The folder after
wp-content/plugins/orwp-content/themes/names the plugin or theme involved. - The line number after the colon. A developer will want it; you mostly need the file.
Stack traces
Fatal errors are often followed by lines starting with #0, #1, #2 and so on, ending with thrown in and a path. This is the stack trace: the chain of calls that led to the failure. Read it from the top. The first line that mentions a plugin or theme folder rather than wp-includes is usually the real culprit, because WordPress core is mostly being asked to do something by that plugin, not failing on its own.
Web server entries look different
Apache and Nginx entries carry their own timestamp format, the client IP, and a message such as a permissions refusal or an upstream timeout. The path in them is a file or folder on disk, not a plugin function. If you see “Permission denied” alongside a path, the fix is with file ownership or permissions, which our post on WordPress file permissions explains.
A method for finding the line that matters
Large logs are mostly noise. This approach narrows them down quickly.
- Reproduce the error and write down the time. Load the broken page, note the exact minute, and convert it to UTC if the log uses UTC.
- Jump to the end of the file. New entries are added at the bottom. Read upwards from the last line to your noted time.
- Search for “Fatal”. If the site is down or showing a critical error, a fatal error near your time is almost always the cause. Ignore everything else for now.
- Note the plugin or theme folder in that entry’s path.
- Check whether it repeats. The same fatal error appearing on every request confirms it. A single one from three days ago is probably history.
- If there are no fatal errors, look for warnings that mention the page or feature that is broken, and for “memory” or “timeout” messages.
- If the WordPress log is empty, move down a layer to the PHP and web server logs for the same minute.
If you have command-line access, tail -n 50 on the file shows the last fifty lines, tail -f shows new entries as they arrive while you reload the page, and grep "Fatal" filters out everything else. These only read the file and are safe to run.
Common entries and what they usually point to
| Entry contains | Usually means |
|---|---|
| Allowed memory size of … bytes exhausted | Something needed more memory than PHP allows, often a heavy plugin or a large import. |
| Call to undefined function | A plugin expects another plugin, or a newer or older version of something, that is not there. |
| Cannot redeclare | The same function is loaded twice, often two copies of one plugin, or a theme and plugin sharing code. |
| Maximum execution time exceeded | A task ran too long and PHP stopped it. |
| Uncaught TypeError | Code received the wrong kind of data, a pattern that often appears after a PHP version change. |
| Permission denied (server log) | The server cannot read or write a file because of ownership or permission settings. |
Things to be careful about
- Logs can contain private data. Paths, email addresses, sometimes snippets of form submissions. Share only the lines that matter, and not in public forums.
- Do not delete logs while investigating. If you want a clean start, download the current file first, then clear it, then reproduce the problem.
- Do not change several things at once based on a log. Fix the top problem, check again, and look at what is left.
- Take a backup before acting on what the log tells you, especially before deleting a plugin folder or editing a file it names.
Turning a log into a useful message
If you are passing the problem to someone else, the log line plus three facts saves a lot of back-and-forth: what you were doing, the time it happened, and what changed recently. Our post on describing a website problem to a developer shows the full checklist. And if the same kind of entry keeps reappearing every few weeks, the article on why WordPress sites keep breaking looks at the patterns behind repeat failures.
For a map of the errors these logs most often explain, from critical errors to database connection failures, see the WordPress errors and fixes guide.
When the log points somewhere you cannot follow
Sometimes the log is clear but the fix is not something you want to try yourself, or the logs are empty and the site is still down. Send us the lines you found, or just tell us you cannot find any, along with a screenshot of what the site shows. We will take a backup, read the logs ourselves, and tell you honestly what they say. If your site is down at this moment, our page on getting a WordPress site back up explains what to send us so we can start. For owners in the USA or UK: we work from India on IST, and payment from abroad is by PayPal or Wise.
Next in this series: Elementor “Preview Could Not Be Loaded”: How to Fix It
