Actionable Error Logging Is More Than Just a `debug.log`

Got a frantic email first thing Monday morning. “THE SITE IS BROKEN!!!” in all caps. The client runs a decent-sized WooCommerce store, and their checkout page was throwing a 500 error. But not for everyone. Total mess. They were losing money with every passing minute, and the only information they could give me was a screenshot of a generic error page. This is the exact moment when you realize the difference between just having error logs and having actionable error logging.

Your `debug.log` is a Graveyard, Not a Toolkit

Every WordPress developer knows about `WP_DEBUG` and `WP_DEBUG_LOG`. You turn it on, and it dumps every notice, warning, and fatal error into a file. And for a simple bug, that’s fine. But on a complex e-commerce site with two dozen plugins, that file becomes a graveyard of useless information. Thousands of lines of PHP notices from a poorly coded plugin, burying the one critical error you actually need to see.

My first thought years ago was to pipe all this into a service like Sentry. Problem solved, right? Well, that worked for about a day. Then I realized I hadn’t fixed the problem; I’d just given it a prettier interface. I had a firehose of data but no information. It was just a cleaner graveyard. That’s not actionable; it’s just more noise.

The Real Fix: Logging with Context

The key isn’t just to log the error message. The error is the *what*. You need the *why*. What was the user doing? What was in their cart? Were they logged in? You need context. Without it, you’re just guessing. For WooCommerce, I stopped relying on generic PHP logs for critical flows and started logging meaningful data myself.

function my_custom_wc_logger( $message, $context = array() ) {
    if ( ! function_exists( 'wc_get_logger' ) ) {
        return;
    }

    $logger = wc_get_logger();
    $context = array_merge( 
        array( 'source' => 'my-custom-function' ), 
        $context 
    );
    
    // Example of adding more context
    if ( is_user_logged_in() ) {
        $context['user_id'] = get_current_user_id();
    }

    if ( function_exists('WC') && WC()->cart ) {
        $context['cart_contents'] = WC()->cart->get_cart_contents_count();
    }

    $logger->debug( $message, $context );
}

// Usage:
// my_custom_wc_logger( 'Payment gateway timed out.', ['gateway_id' => 'stripe'] );

This is a simple example, but it changes everything. Now, instead of just “PHP error on line 123,” I get a log entry that says “Payment gateway timed out” and it tells me the user ID and how many items were in their cart. Now I can start to see a pattern. It’s not random. It’s happening to users with more than 10 items in their cart using a specific gateway. And that was it.

This approach builds on a concept I saw discussed over at carlalexander.ca, where the focus is on making errors manageable. A great idea from that post was renaming “ignore” to “snooze.” Trust me on this, it’s a small detail that makes a huge difference. You’re not dismissing the error forever; you’re just silencing it until the next deployment or for a set period. It lets you focus on what’s critical *right now*.

So, What’s the Point?

Stop thinking of error logging as a switch you flip. It’s a system you design. The goal isn’t to log everything; it’s to log the right things so you can fix problems faster. Before the client even knows they exist.

• Context is King: An error without context is just noise. Log user data, cart data, last actions—anything that helps you reproduce the problem.
• Prioritize Ruthlessly: Not all errors are equal. A PHP notice from a dodgy plugin is not a checkout failure. Use a system that lets you categorize and snooze errors so you can focus on what’s actually costing the client money.
• Make It Someone’s Job: Logging is useless if no one is looking. Someone on your team needs to own the logs, review them, and turn them into tickets.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.