Skip to content

Knowledgebase

Reading WooCommerce logs without exposing customer data

wordpress

Use WooCommerce logs to connect an error with the affected order or integration while keeping customer data and credentials private. Select the relevant source and time range instead of copying every log file into a support request.

01 Locate the relevant record

  1. Record the time, order ID and visible symptom from the affected workflow.
  2. Open WooCommerce > Status > Logs.
  3. Select or search the relevant source, such as a gateway, webhook or fatal-error log.
  4. Compare timestamps carefully, including the timezone used by each system.
  5. Read the lines immediately before and after the failure to understand the sequence.
  6. Save a private excerpt containing the error and non-sensitive references needed for investigation.

Why is there no gateway log?

Some integrations require debug logging to be enabled in their own settings. Enable it temporarily for a controlled reproduction when appropriate, then disable verbose logging after the problem is understood. Check retention and log-level settings before concluding that an event never happened.

What should be removed before sharing?

Redact API keys, signing secrets, authentication headers, cookies, payment tokens, private order links and unnecessary names, addresses or email details. Do not assume every plugin redacts sensitive values consistently. Keep order IDs and timestamps when they are needed, but share them through the appropriate private support channel.

Does a logged error prove the whole order failed?

No. A later step may fail after payment or another action has already succeeded. Compare the order notes and external provider record before retrying. Conversely, a successful HTTP response may only show that a request was accepted, not that the receiving business process completed.

02 Escalate a focused report

Include the affected workflow, software versions, reproduction steps, timestamp and redacted error excerpt. Explain what changed recently and what you have already tested. Avoid sending an entire database or enabling public debug output to make the issue easier to see.

03 Retain and clean up appropriately

Protect log storage from public access and apply a suitable retention period. Preserve relevant incident evidence before routine cleanup, then remove temporary diagnostic files when no longer needed. Recheck the normal workflow after a fix and confirm new logs no longer show the same failure.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support