WordPress error logs: where to find the error and what the messages mean
WordPress error logs are files where the server, WordPress and plugins record the details of errors: the message, the file and the line. Look in three places: debug.log in the wp-content folder (once logging is enabled in wp-config.php), your hosting control panel, and WooCommerce → Status → Logs. Without them, fixing an error is guesswork.
Author: The TellMyShop team. A guide for WordPress site and WooCommerce store owners: the cause, the manual fix and the same work in a chat conversation.
Last updated: · 6 min read
Three places to look
Each of these places records something different. Check them in this order, easiest first.
| Place | What goes there | How to get there | Who usually has access |
|---|---|---|---|
| WooCommerce → Status → Logs, fatal-errors file | PHP fatal errors with file and line | the dashboard, if it works | you |
| debug.log in wp-content | errors, warnings and notices from WordPress and plugins | hosting file manager or FTP, once logging is on | you or whoever looks after the site |
| PHP error log on the server | PHP errors, even when WordPress won't load at all | hosting control panel | the host, sometimes you |
A WooCommerce store has an advantage: the fatal-errors log works without digging through files. WooCommerce itself recommends starting there, as described in WooCommerce's documentation on finding PHP error logs.
How to turn on debug.log step by step
Logging to debug.log is switched on in wp-config.php. That file holds your database password, so work on a copy and be careful. If you're not confident, ask your host or whoever looks after the site.
- Make a copy of wp-config.php in your hosting file manager.
- Open wp-config.php for editing and find the line with WP_DEBUG.
- Set WP_DEBUG to true, add WP_DEBUG_LOG set to true and WP_DEBUG_DISPLAY set to false.
- Save the file and repeat whatever triggers the error, for example open the page or add a product to the basket.
- Open wp-content/debug.log and read the last lines.
- When you're done, set WP_DEBUG back to false.
All the constants and what they do are described in the WordPress debugging handbook. A short explanation of the file itself is in the GreenGeeks glossary entry on WP Debug Log.
The debug.log file sits in a folder that can sometimes be reached from a browser. Don't leave logging on permanently without need, or ask your host to block access to that file.
How to read a log entry
Each entry has a similar shape: date and time, error level, message, and at the end the path to the file and the line number. The path matters most. If it contains wp-content/plugins/plugin-name, that plugin is to blame. If it's wp-content/themes/theme-name, the theme is.
Levels, from the most serious:
- Fatal error: the code stopped, and the page or part of it doesn't work.
- Warning: something went wrong, but the page carries on.
- Notice and Deprecated: notes for developers, usually with no effect on visitors.
Glossary: five common messages
Allowed memory size of … bytes exhausted. PHP ran out of the memory it was given. One heavy plugin or a low hosting limit can be to blame. The memory limit is raised by your host or whoever looks after the site.
Call to undefined function … The code calls a function that doesn't exist. A common cause is a plugin that depends on another plugin which is deactivated, or a theme that no longer fits a plugin after an update.
Maximum execution time of … seconds exceeded. A script ran longer than the server allows. It happens during an import, a large backup or a slow connection to an external service.
Uncaught Error: Class … not found. Part of a plugin's code is missing, for example after a failed update. Reinstalling the same version of the plugin helps.
Cannot modify header information - headers already sent. Something sent text to the browser too early. Very often it's a blank line or a space at the end of functions.php after a manual edit.
The values in messages vary from site to site, so they're replaced with an ellipsis. If the log shows a fatal error and the site is down, go to the guide on the WordPress critical error. For a white screen or a 500 code, read the post on the 500 error in WordPress.
What to send your host or developer
A well-written report saves several rounds of messages. Include:
- the exact message from the log, copied rather than retyped from memory, together with the file path and line number,
- the date and time it first appeared, and whether the error keeps happening,
- what changed just before: a plugin, theme, WordPress or PHP version update,
- on which page and during which action the error appears, for example when adding to the basket,
- the WordPress and PHP versions from Tools → Site Health → Info.
Before sending, remove email addresses and other customer data from the excerpt.
How the chat reads the logs for you
The TellMyShop plugin for WordPress and WooCommerce reads error logs even in TellMyShop Free. Your chat (Claude or ChatGPT) gets the PHP, WordPress and WooCommerce errors from the last few days, grouped: the same message is one row with a count and the date it last appeared. For each, it names the plugin or theme it comes from and explains the message in plain words. Emails, phone numbers and IP addresses in the logs are masked.
You: Since yesterday the basket sometimes won't load. Have a look at the logs.
Your chat: In the last two days there's one fatal error, repeated a dozen or so times:
Allowed memory size exhausted, in a file of the shipping calculator plugin.
It appears only when the basket opens. The plugin got a new version yesterday.
My suggestion: report the error to the author or roll back to the previous plugin version. The memory limit is a matter for your host.
The result in this conversation is an example. The chat reads what has been recorded. If logging to debug.log is off, there'll be nothing in the WordPress log. The chat can't turn it on: wp-config.php is always blocked for the plugin, in every version. That's for you, your host or whoever looks after the site.
Reading the logs, site health and the plugin list is enough for a diagnosis, and it's free. When a plugin is the cause, in TellMyShop Pro the chat can deactivate or update it once you turn on the Plugins switch for 24 hours, always with a preview and after your approval. You can download the free version from the TellMyShop Free page, Pro is described on the TellMyShop for WordPress and WooCommerce page, and the differences are on the pricing page.
Questions and answers
Where is the debug.log file in WordPress?
By default in the wp-content folder, but only when WP_DEBUG and WP_DEBUG_LOG are turned on in wp-config.php. The file is created at the first error after logging is enabled. If it isn't there, logging is off or there have been no errors since it was turned on.
Will turning on WP_DEBUG show errors to customers?
It can, if you leave error display on. On a live site you log to a file with display turned off, meaning WP_DEBUG_DISPLAY set to false. Then errors go only to debug.log.
Do Deprecated warnings need fixing straight away?
Usually not. They say a plugin or theme uses a function that will disappear from PHP or WordPress in the future. The site works, but before changing PHP version it's worth reporting them to the plugin author or looking for an update.
Can an error log contain customer data?
Yes, email addresses, IP addresses or fragments of requests sometimes end up there. So don't post the whole file on a forum and don't leave logging on without need. The TellMyShop plugin masks emails, phone numbers and IP addresses when it reads logs.
Who has access to the server logs?
Your host. The server's PHP error logs are usually in the hosting control panel, in the statistics or logs section. If you can't see them there, ask support for the excerpt from the time the error appeared.
WordPress is a trademark of the WordPress Foundation. WooCommerce is a trademark of Automattic Inc. Claude is a trademark of Anthropic PBC. ChatGPT and OpenAI are trademarks of OpenAI. TellMyShop is not affiliated with these companies.