JavaScript Error Detection
What the checkout-page listener reports, how repeated errors escalate to Critical, and what it cannot see.
On this page
What it does
PRO loads a lightweight script only on your WooCommerce checkout page (this includes the order-received page that follows checkout, and works with both the classic and the block checkout). It reports uncaught JavaScript errors and unhandled promise rejections to your own site, so you hear about a broken checkout before customers tell you.
What is reported
Only technical details: the error message, the file, the line and column, and the error type. No form values, cart contents, order data or personal information are collected. The script reports errors from any script on the page, including third-party ones such as analytics, chat or payment widgets.
How severity works
Each distinct error (same message, file and line) becomes one issue. Its severity depends on how many times that exact error has been recorded in total, with no time window:
| Times recorded | Severity |
|---|---|
| 1 | Low |
| 2 | Medium |
| 3 or more | Critical |
Whether a level emails you depends on the Issue Emails setting (by default High and above, so by default only the third recording sends an email). These values are fixed in this version. A first occurrence may just be one visitor’s browser extension, so it starts at Low. An error that keeps coming back is clearly a real problem.
When an issue resolves
An error’s issue resolves automatically after 30 days without it recurring. If it comes back later, the issue reopens.
Built-in protections
- The script sends at most 10 reports per page load.
- Your site accepts at most 20 reports per minute from one visitor’s address and drops the rest.
- Each field is capped at 300 characters.
- Nothing is accepted while the PRO license is inactive.
What it cannot detect
- A broken checkout that throws no error. For example, a payment form that fails to load without raising a JavaScript error, or a button hidden by a style rule.
- Errors on the cart, product or other pages. The listener runs on the checkout page only.
- The details of errors from other websites’ scripts. Browsers hide them and report only “Script error.”, so you can see that something failed but not what.
- Server-side errors. A PHP error that stops checkout before the page loads is not a browser error.
Example. A plugin update breaks the “Place order” button with a script error: PRO records it and raises an issue. A cached checkout page whose form silently stops submitting, with no error in the browser console, is something PRO cannot see.
Still need help?
Search the docs first — or open a ticket and our team will pick it up from the Support screen.