Where to find and how to read WordPress and WooCommerce logs
A WooCommerce store writes its errors to several separate logs depending on where they originate: WordPress core, the WooCommerce plugin itself, and the server. Knowing where to look saves time wasted on the wrong file.
The three logs to know
-
wp-content/debug.log
Once WP_DEBUG_LOG is enabled in wp-config.php, WordPress writes every PHP error, warning and notice generated by core, plugins and the theme here, along with the file and line responsible.
-
WooCommerce > Status > Logs
Accessible from the WordPress admin, this screen lists logs split by source: payment, webhook, email sending, stock synchronisation. It's the first place to check for an order or payment problem.
-
The server logs
Accessible via the hosting panel or SSH, these record server-level PHP errors (error_log) as well as the Apache or Nginx logs, useful when the site is unreachable even before WordPress loads.
-
Pinpoint the exact time
As with any multi-source diagnosis, the precise time of the incident makes it possible to find the same error across several logs and confirm whether several symptoms share the same cause.
-
Isolate the source when several plugins are logging errors
On a site with many active plugins, debug.log can contain noise unrelated to the current problem; the plugin's name or its path under wp-content/plugins generally appears in the error line itself.
Why WooCommerce has its own logs
WooCommerce records certain events separately from debug.log because they aren't always PHP errors in the strict sense: a payment webhook received but rejected, a synchronisation attempt with a gateway that fails silently, or an order confirmation email that couldn't be sent. These events are only visible from WooCommerce, Status, Logs.
The debug.log file, on the other hand, captures anything that qualifies as a PHP error or warning in the strict sense: a deprecated function called by a poorly maintained plugin, a null value used where an array was expected, or a fatal error that stops the page from loading. It's the most useful source when facing a critical WordPress error.
[24-Jul-2026 09:14:02 UTC] PHP Fatal error: Uncaught Error: Call to undefined function some_removed_function() in /wp-content/plugins/exemple-extension/exemple.php:42The severity level changes how to proceed
Not every line in debug.log deserves the same urgency. A PHP Fatal error stops the page from executing and generally explains the white screen or critical error message directly. A PHP Warning or PHP Deprecated notice usually doesn't stop the page from displaying, but flags code that will become incompatible at the next PHP or WordPress version upgrade.
On an active store, it's common to find several hundred lines of notices or warnings unrelated to the current problem. Focusing first on fatal errors, then on warnings whose timestamp matches the incident precisely, avoids wasting time fixing messages unrelated to the symptom being investigated.
Frequently asked questions
debug.log is empty even though the site is crashing, why?
Can I delete debug.log without risk?
Do the WooCommerce logs also cover third-party payment plugins?
How can I tell which plugin wrote a given line in WooCommerce > Status > Logs?
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.