How to Read the WordPress Error Log: Every Message Type Decoded

Every WordPress diagnosis ends at the same place: a log line. The problem is that logs look hostile — timestamps, paths, jargon — so most people skip them and guess instead. But a log line has exactly three useful fields and a small vocabulary. Learn both and every error becomes a next action. This guide uses real lines from our client audits.

Turning the log on

In wp-config.php, above the “stop editing” comment:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the failing page once — errors are written to wp-content/debug.log. DISPLAY stays false on live sites: showing errors publicly leaks paths and versions. Hosting-level logs (cPanel errors, nginx error log) record the same events and are readable even when wp-config is unreachable.

The anatomy of a line

[20-Oct-2026 08:14:03 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wcf_checkout() in /home/site/wp-content/plugins/checkout-kit/includes/render.php on line 88

• Severity: Fatal error — execution stopped here.
• Message: Call to undefined function wcf_checkout() — the actual problem.
• Location: the path names the plugin (checkout-kit), the file, and the line.

Three fields. The location usually hands you the guilty plugin directly; the message tells you what went wrong with it.

The five severities, ranked by urgency

The fatal-error messages that cover 90% of cases

• Call to undefined function X() — the code called a function that does not exist: a companion plugin is missing or outdated, or a partial update happened. Fix: update both plugins; deactivate if the update fails. (The full playbook: critical error guide.)
• Class "X" not found — same story, object edition: usually an autoload/version mismatch between two plugins bundling the same library.
• Cannot redeclare function X() — two plugins bundle the same helper. Find both from the path in a second log line; remove or update one.
• Allowed memory size ... exhausted — the memory ceiling; the named file is the victim, the eater needs the memory diagnostic.
• Maximum execution time exceeded — a request ran too long: slow external API or runaway query. Note what the page was doing when it died.
• Failed opening required ... — files missing mid-plugin: corrupted install. Delete the plugin folder and reinstall clean.

Reading habits that make logs useful

• Read bottom-up: the last lines are the most recent events.
• Correlate timestamps with when the symptom occurred — logs accumulate weeks of noise.
• Trace the repeat offender: ten warnings from the same plugin file is a diagnosis, even without a fatal.
• Timestamps are UTC — align with your timezone before correlating with analytics or order logs.

After the fix

Clear the page cache (cached error pages survive their own cure, as the WSOD guide warns), then watch the log for a day: the same error returning means the fix addressed the symptom, not the cause. The free audit reviews recurring log errors as part of its stability check.