Your logs cannot reach backwards

By the time you go looking for evidence, it either exists or it does not. That is the whole argument for switching WooCommerce logs on before an incident rather than after one. Because logging records only what happened while it was running, it cannot reach backwards. So the setting worth checking today is the one you will wish you had checked last week.

Order notes and the orders list share a limit that is easy to miss. Both need an order to exist. WooCommerce logs do not, which is why they hold the part of the story nothing else kept.

Why WooCommerce logs see what the orders list cannot

To begin with, the orders list shows orders. And the notes panel on each order shows what happened to that order, including a gateway's own decline reasons. Both are useful. Neither exists for a request rejected before order creation, for a gateway call that errored on the way out, or for a POST that failed validation and went nowhere.

That material lives in logs or nowhere at all. Specifically, it lives wherever some piece of code chose to write it: WooCommerce core, your payment gateway, or a plugin sitting in front of checkout.

Where the screen is, and what it controls

The developer documentation gives the location in one line. "You can view the entries created by the logger by going to WooCommerce > Status > Logs." From there a Settings link opens the logger's own configuration.

Four things sit on that screen. First, a checkbox that turns logging off entirely, which the WooCommerce logging guide argues against: "Uncheck the box here to turn off all logging. This is not recommended in most circumstances, as logging can provide valuable information about what is happening on your site!" Then storage, retention and a severity threshold. Each of those three can quietly cost you an investigation.

Two places to keep WooCommerce logs

Core ships two storage methods. Files hold entries on disk, named by source and by date. Alternatively the database handler writes rows instead, and the docs are specific: "Log entries are recorded to the database, in the {$wpdb->prefix}woocommerce_log table."

Notably, files are the default. In the logging settings class, default_handler is set to LogHandlerFileV2. Those files land in the wc-logs subdirectory of your uploads folder, which means the documentation has to flag what follows: "WooCommerce adds an .htaccess file to prevent access to wc-logs, but not all web servers recognize that file."

Database rows sort and filter more comfortably in the admin, at the cost of weight in the table your store already leans on. Either way, one detail catches people out when they switch. "If you change this setting, and you already have some log entries, those entries will not be migrated to the other storage method, but neither will they be deleted."

Eight levels, and a threshold that can mute them

Also, every entry carries a severity, and the docs list all eight: "emergency, alert, critical, error, warning, notice, info, debug". In core, the WC_Log_Levels class points at RFC 5424 for the definitions.

Levels exist so entries can be filtered, which is where the risk sits. Set the threshold to error and you keep the crash while losing everything that explained it. Whether that hurts depends on your gateway, since every integration picks its own level for request and response detail. In practice plenty of that detail sits at debug or info. Consequently the docs attach a warning: "Use this setting with caution!"

By default the threshold is none, as the settings class confirms. Nothing gets filtered out until somebody changes it.

Retention puts a clock on your evidence

Retention decides whether an investigation is possible at all, because it deletes WooCommerce logs on a timer. Its description in the admin says so plainly: "This sets how many days log entries will be kept before being auto-deleted." Thirty days is the default value in the WooCommerce source.

Deletion also behaves differently depending on storage: "If log entries are stored in the file system, the entire log file that is beyond the retention period will be deleted, while with database storage, individual log entries will be deleted."

Worth knowing too, retention is a privacy question and not only a disk-space one. Because the context array can carry structured data, and the guide suggests exactly that: "For example, in a log entry about an order, you may want to include contents of the related order object." An address, an email and an IP can therefore sit in a text file under uploads for as long as you allow. Keeping everything forever is a decision about personal data.

Reading WooCommerce logs after a suspicious run

In practice a short routine beats scrolling. Once you have a window of bad orders, work through it in order.

1. Fix the window first. Take the timestamp of the earliest bad order and the latest, then widen by an hour at each end.
2. Filter by source before reading a single line. Your gateway's source name is the one that matters, and core writes under its own.
3. Read the levels, not just the text. A run of error entries with no matching orders means attempts that died before checkout finished.
4. Count entries against orders. Far more log lines than orders in the same minutes is the shape you are looking for.
5. Treat any IP in the log exactly as you treat the one on an order, because the recorded address comes from a header rather than from the network.

Then carry what you found back to the orders screen and read it beside the wall of failed orders it produced.

What WooCommerce logs are not

In short, three honest limits, and they matter more than any setting above.

They are not a request log. Logs hold what code chose to write, so a request nothing observed leaves no trace, and silence is not proof.

Your web server's access log is the complementary record. It lists every request that reached the server, whether or not any PHP cared about it. Reading both together is the point.

Finally, nobody can backfill a log. Turn logging off during the week that mattered and that week is simply gone.

Where Checkout Bouncer fits

Checkout Bouncer works one step earlier than any log you read afterwards. Because it scores checkout requests with Google reCAPTCHA v3 before an order exists, its job is to shrink the volume that reaches your evidence trail in the first place. The plugin is free, GPL and listed on WordPress.org.

Even so, its limits deserve stating plainly. The plugin guards the WooCommerce checkout only, so login, registration, comments and contact forms fall outside it. Nor does it act as a firewall or a malware scanner. And it uses reCAPTCHA v3 only, never v2 or another provider.

Logging and a checkout guard answer different questions. One tells you what already happened. Meanwhile the other decides what gets to happen next. If you want to know which routes into your checkout currently answer, the free scanner reports back in about two minutes.