How to read the WordPress debug log
Every line in debug.log has four parts: time, severity, message and file. Here is how to read them and trace an error to the plugin or theme behind it.
On this page
Every line in debug.log has four parts: when it happened, how serious it is, what went wrong, and the file and line where it went wrong. The file path tells you which plugin or theme is responsible.
[10-Oct-2026 13:02:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_price_table() in /home/site/public_html/wp-content/plugins/shop-extras/includes/pricing.php:42
Stack trace:
#0 /home/site/public_html/wp-includes/class-wp-hook.php(324): shop_extras_render()
#1 /home/site/public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters()
#2 {main}
thrown in /home/site/public_html/wp-content/plugins/shop-extras/includes/pricing.php on line 42What do the parts of a log line mean?
| Part | In the example | What it tells you |
|---|---|---|
| Time | [10-Oct-2026 13:02:11 UTC] | When it happened. The log is usually in UTC, not your local time. |
| Severity | PHP Fatal error | How serious it is. See the next table. |
| Message | Call to undefined function get_price_table() | What went wrong. |
| File and line | .../plugins/shop-extras/includes/pricing.php:42 | Where it went wrong. |
Which errors matter?
| Severity | Does the page still load? | What to do |
|---|---|---|
| Fatal error | No | Fix now. This is what causes a white screen or the "critical error" message. |
| Parse error | No | A typing mistake in a PHP file, often after a manual edit. Undo the edit. |
| Warning | Yes | Something failed but the page carried on. Worth fixing. |
| Notice | Yes | Sloppy code. Usually harmless. |
| Deprecated | Yes | Works today, will break in a future version of PHP. Report it to the plugin author. |
How do I tell which plugin caused the error?
Read the file path and find the folder after wp-content.
| The path contains | The code belongs to |
|---|---|
wp-content/plugins/shop-extras/ | The plugin in the shop-extras folder |
wp-content/themes/my-theme/ | The theme in the my-theme folder |
wp-content/mu-plugins/ | A must-use plugin, often installed by your host |
wp-includes/ or wp-admin/ | WordPress itself, but keep reading |
The error is in wp-includes. Is WordPress broken?
Almost never. When the path points into WordPress's own files, a plugin or theme usually handed WordPress something it could not use. Read down the stack trace, the numbered lines under the error, until you reach the first path inside plugins/ or themes/. That is the code to look at.
How do I read a stack trace?
A stack trace lists the calls that led to the error, most recent first. Line #0 is where the failing code was called from, #1 is what called that, and so on down to {main}, the start of the request. You rarely need all of it. Look for the first line that names a plugin or theme.
The same line appears hundreds of times. Why?
The log gets one line every time the code runs, so a notice on every page load fills the file fast. Count distinct messages, not lines. One real fatal error can be buried under thousands of copies of one harmless notice.
How Paul Bunyan helps
Paul Bunyan does this reading for you. Errors are grouped, so a thousand copies show as one line with a count. Each one is already matched to its plugin or theme, with the file and line, and you can open the request it happened in to see what else was going on.