Two streams. One diagnosis. In under five seconds.
Most WordPress failures leave evidence in two places at once: the browser sees a failed network request, the server recorded the PHP error that caused it. Loupely reads both simultaneously, correlates the signals, and tells you what they mean together.
Reads everything the browser knows the moment you click the icon. JavaScript errors, network failures, CSS conflicts, session state, platform context, credential scan. All captured before you see the result.
Has been recording silently since you installed it. Eleven categories of server failure, captured automatically. When you click capture, it sends the last 72 hours of PHP errors, hook failures, email failures, WooCommerce events, auth failures, outgoing HTTP failures, and more.
Everything the browser knows at the moment of the break.
The extension captures what is visible in the browser right now: every error that has fired, every request that has failed, every CSS rule that is winning when it should not be. Don’t refresh before you click. Refreshing clears the evidence.
Every JavaScript error that fired on the page: the error message, the script file it came from, the line and column number, and the stack trace. Includes errors from plugins, themes, and third-party scripts.
When something on your page stops working or a button does nothing, a JavaScript error is usually why. Loupely captures it and names the plugin or script responsible.
Every failed network request: the URL, the HTTP method, the status code returned, the response time, and whether the request was blocked by a CORS policy or failed mid-connection.
Your checkout form submits but nothing happens. The browser sent a request to your server and got nothing back. Loupely captures the exact request that failed and what the server said in response.
Every console.error and console.warn message logged during the page session, with the source script and timestamp. Plugin conflicts often log warnings that explain the failure before anything visibly breaks.
Two plugins are fighting over the same function and one of them is logging the conflict. You would never see it. Loupely captures it before you refresh the page and lose it.
Whether the user is logged in, the WordPress nonce values present on the page, cookie state, and any session-related data visible in the browser at the time of capture.
A form that works when logged in but fails for customers who are not is a session-dependent failure. Loupely captures the login state so the diagnosis can distinguish between the two scenarios.
WordPress version, active theme and child theme, list of active plugins with versions, page builder detected, and the page type being captured.
When you send the capture file to a developer or paste it into an AI tool, they know exactly what environment they are working with. No follow-up questions about which plugins you have or what version of WordPress you are running.
Core Web Vitals at the time of capture: Largest Contentful Paint, Total Blocking Time, and Cumulative Layout Shift. Time to First Byte. Total page load time. These give the server-side correlation layer context for slow-page diagnoses.
Your site is slow and you do not know why. When the browser reports a 4-second LCP and the server shows 300 database queries on the same page load, Loupely connects the two and names the cause.
What the browser can’t see. Eleven categories of server failure, all captured automatically.
The Chrome extension sees what the browser sees. Everything that happens on the server is invisible to it. PHP fatal errors, failed payment gateway connections, upload failures that appear to succeed, login failures that produce no error message, server memory running low before a crash: none of these appear in the browser. The plugin captures them directly from the server, across eleven failure categories, all running automatically from the moment it is installed.
Every PHP error that fires on your site: fatal errors, warnings, notices, parse errors, and deprecated function calls. Each record includes the severity, the error message, the file and line it came from, and the plugin or theme responsible.
Your site went white after a plugin update. Your host says the server is fine. The PHP error is in the record, named to the exact plugin and line that failed. If it came from your theme, Loupely names the theme, not just “unknown source.”
Every failed login attempt recorded with the error type: whether the username does not exist, the password is wrong, or a security nonce expired. Usernames are never stored. The pattern of failures is what matters for diagnosis.
Your members portal is broken and people cannot log in. Loupely records every failure type so the pattern is visible: is it everyone, or specific accounts, or a session expiry problem affecting all users after a certain time.
Every plugin update and activation event with timestamps, cross-referenced against PHP errors and other failures to identify when a problem started after a specific update, even if the update happened hours before the failure became visible.
You updated three plugins today and now something is broken. Loupely correlates the error timestamp against each update timestamp and names the one that started the problem.
Every wp_mail() call and its result: success or failure, the error message on failure, the SMTP response code, and the plugin that triggered the send. Email failures are kept for 30 days because SMTP problems that started weeks ago are one of the most common invisible failures.
Your contact form stopped sending emails and you did not know for six weeks. Every failed attempt has been recorded since the failure started. Loupely reads the SMTP error and tells you exactly what expired or misconfigured.
Every failed outgoing HTTP request made by WordPress or any plugin: payment gateway connections, shipping rate lookups, email delivery API calls, webhook deliveries. The destination host is recorded with the specific error type: timeout, connection refusal, or SSL certificate failure.
Your checkout processes but payment never goes through. The browser looks fine. The problem is that your server could not reach Stripe at the moment of checkout. Loupely captures the failed outgoing connection so the diagnosis is specific.
Order status changes, payment gateway responses, checkout hook failures, cart validation failures, and stock mismatches where a product shows as in stock on the product page but is treated as out of stock in the cart. All captured with timestamps and the specific hook involved.
Your product page says 12 in stock. Your customers add it to their cart and get told it is unavailable. Loupely captures both the stock status and the cart validation failure and surfaces them together so the diagnosis is specific.
Upload failures that produce no visible error: the progress bar completes, the upload appears to succeed, and nothing appears in the media library. Also captures when the uploads directory itself is not writable, which causes upload failures across the entire site.
You upload an image, the progress bar fills to 100%, and nothing appears. No error. No explanation. Loupely records the failure at the point it actually occurred, with the error code that explains whether it was a permissions problem, a file type rejection, or a size limit.
WordPress scheduled events and their results: which hook ran, when, how long it took, and whether it completed or failed. Includes events that were scheduled but never fired, which indicates a broken cron configuration rather than a hook failure.
Your scheduled posts stopped publishing. Your membership renewals are not processing. Loupely identifies whether it is a cron configuration problem or a hook failure, and names the specific hook involved.
Memory usage at the time of every PHP fatal error. Disk space checked at capture time: when less than 50MB remains, uploads and caching fail silently. Execution time tracked against the PHP limit to identify requests hitting the timeout wall.
Your site goes blank on the checkout page. The PHP error log says fatal error. Loupely adds the memory context: the fatal occurred when memory was at 97% of the server limit. The problem is not WooCommerce. The problem is your memory limit.
Several PHP settings, when misconfigured, cause failures that look like plugin bugs but are actually server configuration issues. Captured at request time: max_input_vars (when too low, large forms like WooCommerce checkout silently truncate), and SSL certificate status (expired or expiring within 14 days).
Your WooCommerce checkout stops working for some customers. No error. Loupely finds that max_input_vars is too low, meaning large checkout forms silently drop fields. The fix is a single line in wp-config.php.
Failures on the WordPress admin-ajax.php endpoint, which handles WooCommerce cart updates, Elementor save operations, and custom plugin actions. Captured when an ajax request starts but does not complete successfully, with the action name recorded.
You click Save in Elementor and nothing happens. Or you add an item to your cart and the count does not update. These are ajax failures invisible to both sides. Loupely captures the action that failed so the diagnosis names it specifically.
Cross-signal correlation.
When both streams have completed, Loupely runs a local correlation layer before making any API call. It looks for signals in the browser that point to the same root cause as signals from the server, and elevates the combined finding. A checkout failure shows up in the browser as a failed POST request and on the server as a PHP fatal in a payment hook. Loupely recognises that they are the same event and surfaces them together as one finding, ranked as the most likely root cause.
→ 500 Internal Server Error
→ Response: empty body
→ woocommerce-payments/checkout.php:247
→ plugin_source: woocommerce-payments
“Your checkout is failing because a PHP fatal error in the WooCommerce Payments plugin is preventing the checkout hook from completing. The error started 2 days ago, after a plugin update. Roll back WooCommerce Payments to the previous version, or contact the plugin developer with the capture file.”
The triage. Your exact next step.
The diagnosis tells you what is wrong. The triage tells you what to do about it. Loupely selects one triage route based on what it found, writes the pre-written message for you, and gives you the specific next step. Not a list of things to try. The one thing to do right now.
When the failure is server-side and your host’s support team can resolve it. Loupely writes the message you send them, with the technical details they need. You open their live chat and paste it.
“Contact SiteGround support. Here is the message to send them.”When a specific plugin is identified as the source of the error. Loupely surfaces the plugin’s support URL and writes the support message with the relevant error details already filled in.
“The error is in WooCommerce Payments. Here is the support link and what to include.”When an error started immediately after a plugin update. Loupely names the plugin, confirms the update timeline, and links to WP Rollback with instructions. No developer required.
“Roll back WooCommerce Payments using WP Rollback. Here’s how.”When the fix is something you can do without a developer: updating an expired SMTP credential, clearing a specific cache, re-saving a settings page, or replacing a missing configuration value.
“Your SMTP password expired. Go to Settings and update it.”When the fix requires code changes. The capture file contains everything your AI needs to understand the problem without you having to describe it. Upload it to Claude, ChatGPT, or Gemini for a code-level fix.
“This requires a code change. Upload the capture file to your AI tool.”When the fix is beyond self-service. The capture file is a complete structured diagnostic that any developer can read immediately, without asking follow-up questions about what is broken.
“Send the capture file to a developer. They’ll know what to do with it.”What Loupely never captures.
The credential scan runs client-side before any file is created. Every category of sensitive data listed below is actively excluded from the capture file. The file never contains them, and they are never sent anywhere.
Customer names, email addresses, shipping addresses, and order details are never captured. The capture is about your site’s health, not your customers’ data.
No payment card numbers, CVV codes, or bank account details. Loupely captures payment gateway responses and error codes, not the card data that flows through them.
The credential scanner detects API keys, authentication tokens, database passwords, and secret keys in the captured data and removes them before the file is created. You see a notification of what was removed.
Failed login attempts are captured by error type, not by username. The username may be a real user’s email address. It is never stored.
Full server file paths expose your directory structure. Loupely stores relative paths from the plugin or theme root, never the full absolute path from the server root.
Form submissions and request bodies may contain personal data. Loupely captures the request URL, method, and response status, not the content of what was submitted.
Install it free. The evidence starts accumulating immediately.
The next time something breaks, you will already have the record. Free to install. The capture file always downloads free.
Join the waitlist