What correlation rules are #
Loupely captures 2 separate streams of diagnostic data for every session: browser-side signals (JavaScript errors, network requests, console output) and server-side signals (PHP Errors, Hook Execution, WooCommerce pipeline events, REST API responses). Each stream has value on its own. But the most important diagnostic work happens when Loupely looks at both together.
Correlation rules are the patterns Loupely uses to connect signals from the 2 layers and identify the causal chain behind a failure. A single JavaScript error in the browser doesn’t tell you much. A PHP Fatal Error on the server doesn’t tell you which front-end behavior it caused. The correlation rule that connects “JavaScript Ajax Request returned a 500 response” to “PHP Fatal Error in WooCommerce payment plugin fired at the same timestamp” is what produces an actionable diagnosis rather than a list of unconnected errors.
Why cross-signal correlation matters #
Most WordPress debugging approaches look at one layer at a time. You open the browser console and look for JavaScript errors. Or you check the PHP error log. Or you look at WooCommerce order notes. Each of those layers tells a partial story. The actual failure chain often spans all 3.
A checkout that fails silently is a good example. The customer clicks Place Order. The browser sends an Ajax Request. The server receives it, tries to process the payment, fires a PHP error in a Payment Gateway plugin, returns a 500 response. The browser receives the 500, fires a JavaScript error, and the Checkout Button does nothing. What you see: the button did nothing. What the browser console shows: a JavaScript error. What the PHP error log shows: a PHP fatal. Neither alone names the cause. Both together, correlated by timestamp and request path, name it precisely: the PHP fatal in the Payment Gateway plugin caused the 500 response that caused the JavaScript error that caused the button to do nothing.
That’s what correlation rules do.
How correlation rules work in practice #
Correlation rules are pattern-matching logic applied to the combined capture payload. Each rule defines:
- A browser-side signal pattern (a specific type of JavaScript error, a network request to a specific endpoint returning a specific status code, a console warning with specific text)
- A server-side signal pattern (a PHP error in a specific category of plugin, a hook that failed to fire, a WooCommerce pipeline stage that didn’t complete)
- The timing relationship between them (the server-side event preceded the browser-side event within the capture window)
- The failure class that this combination represents (and the appropriate triage route)
When a capture matches a rule, Loupely assigns the corresponding failure class with a confidence score. A high-confidence match produces the specific diagnosis text you see in the popup. A low-confidence or no-match result produces a Null Result. See The Null Result: What It Means for what to do when no rule matches.
Rules are updated as new failure patterns emerge #
New WordPress Plugin versions, WooCommerce updates, and PHP version changes introduce new failure patterns that don’t match existing rules. Loupely’s correlation rule set is updated when new patterns are identified, either from support cases, user reports, or active analysis of the WordPress ecosystem. If you encounter a failure that Loupely doesn’t diagnose but that produces consistent signals across multiple captures, that’s worth reporting to support@useloupely.com. Recurring unmatched patterns are candidates for new correlation rules.