In short
What it measures
three counts of JavaScript errors produced when the page loads.
When it’s triggered
as soon as any of the three goes above zero. Severity: Important.
Why it matters
an error doesn’t warn the visitor; it leaves them a button that does nothing.
Wakaris data
35.3% of the pages analyzed fail this finding.
What this finding is and what it measures
A JavaScript error isn’t like a broken link. A broken link warns you: an error page appears and the visitor knows what happened. A JavaScript error warns nobody: the button gets clicked, nothing happens, and whoever clicked it concludes the website doesn’t work or that they did something wrong.
The finding counts three different things, and there are three because the browser handles them differently. Console errors are everything recorded in the incident log the browser keeps on its own. Uncaught exceptions are code failures nobody anticipated that abort whatever was running. And rejected promises are background operations (a request to a server, a payment gateway, a data load) that failed and whose failure nobody picked up.
All three count separately and share the same threshold: any of them above zero triggers the finding, with no bands. One error and thirty give the same warning with the same severity, so the number matters as much as the finding.
How it’s measured
Wakaris loads your page in a real browser, listens to what happens while it’s being built and gives you the three counts. It’s the direct way to know whether your page fails on load, without installing anything or creating an account, and the result can be read at a glance because it’s three numbers.
That they’re three different mechanisms is the most misunderstood technical detail. According to MDN, the window’s error event fires when a resource failed to load or couldn’t be used (for example, if a script has an execution error), and it’s only generated for errors thrown synchronously, during the initial load or inside event handlers. Promises take a different path: if a promise is rejected and has no rejection handlers attached, what fires is the unhandled rejection event, which MDN describes as sent to the global scope when a promise with no rejection handler is rejected. Watching only the first leaves the second out entirely.
And there’s a limit: the check observes one load, with nobody clicking anything. Errors that only show up when you interact aren’t counted here.
Why it matters
It matters because the damage is both functional and silent, which is the worst possible combination.
An uncaught exception stops execution of the block where it happens. If that block was the one connecting the “Add to cart” button to the cart, the button is still there, with its color and its shadow, and it does nothing. Nobody sees an error message: the visitor tries twice more and leaves. No complaint ever arrives, so the failure can live on for months.
Rejected promises are even more treacherous, because they usually wrap exactly what you care about getting paid for: a form submission, a call to the payment gateway, a price load. MDN notes that listening for that event is useful for debugging and for providing fallback error handling for unexpected situations; if you don’t listen, the unexpected situation resolves itself by leaving the screen half-done.
And console errors matter as a symptom even when they don’t break anything visible: they’re the sign that something in the setup isn’t working the way its author expected.
Common causes
Interface errors almost never come from a single badly written line: they come from pieces that no longer fit together.
The most common cause is an external script that has changed or disappeared: a tracking tag, a chat, a map, a player. The provider updated their code or retired a version, and your page keeps calling it. The second is a conflict between extensions or plugins: two that load the same library in different versions, and the one that wins breaks the other.
The third is load order. A script that expects to find an element on the page runs before that element exists, and fails; it usually shows up right after changing a template or moving a block around. The fourth is data that doesn’t arrive as expected: a request that returns an empty field where there used to be a number, and the code that was going to use it breaks.
And the fifth, the most common with promises: a network call that fails (a timeout, an expired permission, a moved address) and for which nobody wrote the “what if it fails”.
How to fix it
You fix it by elimination, and the order saves a lot of time.
Start by knowing what fails and where it comes from: Wakaris gives you the three counts for your page, and if you need to see the trace line by line you also have the browser’s own console. With that you already know whether the failure is in your code or in someone else’s script.
If it’s someone else’s, decide: update it to the current version or remove it. A third-party script that throws errors and nobody uses anymore is the easiest cause to eliminate in the whole analysis, and it often takes out several counts at once.
If it’s yours and it’s an ordering problem, delay execution until the page is built instead of launching it at the start. And if it’s data that doesn’t arrive as expected, check it before using it instead of trusting it.
For rejected promises, the rule is short: every operation that can fail needs its failure branch, even if it’s only to show an honest message. And add a global fallback handler for whatever slips through. When you’re done, run the page through Wakaris again: all three counts should be at zero.
Ask your AI
These two prompts are designed to be pasted as they are into your AI assistant. Pick the one that fits your situation: the first if you’ve already measured your site and want to fix the errors; the second if you got here without measuring anything and want to know whether it affects you.
A. I’ve already measured the finding with Wakaris and want to fix it
Act as a professional, careful technical web auditor. Your goal is to help me understand a specific finding about my website and decide what to do about it, without making anything up. Context: I got this finding from Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, user experience, accessibility and legal) and explains each problem in the language of each role on a team. The finding is: Interface errors. My page throws JavaScript errors while loading, counted in three groups: errors logged to the console, uncaught exceptions and unhandled rejected promises (reference: the finding appears as soon as any of the three counts goes above zero). Rules you must follow at all times: 1. Don’t assume anything about my website or my code. Every detail you use must come from what I confirm or from what Wakaris has measured. If you don’t know it, ask me before stating it. 2. Before giving me conclusions, ALWAYS ask me these questions, together and in plain language, to find out where the error comes from and who can touch it: a) Paste the Wakaris result here: the three counts, the page analyzed and, if you have them, the error messages. If you don’t have it, measure your website with Wakaris and come back with the result; without knowing which of the three counts is high, nothing can be pointed in the right direction. b) What platform is your website on, and on what template or theme? c) What third-party scripts do you have installed: tracking, chat, maps, reviews, payments? d) Has something specific on the website stopped working, and since when? e) Did you change anything just before: a template, an extension, an update? f) Who can edit the code or disable extensions: you, an in-house technician or an agency? 3. Every statement or recommendation must be justified in relation to MY context, not in general. If you suspect a specific script, explain why and how to check it. 4. Always state your level of certainty. You can’t see my page or its code: if something is a hypothesis, say so. 5. Don’t suggest irreversible or risky technical changes (editing theme files, disabling extensions in production, touching the payment gateway code) without first warning me about the risk and that a backup or a test environment is advisable. 6. If you need information that can only be obtained by measuring the website (the real counts, or whether the fix worked), tell me and recommend I run the page through Wakaris again: that gets measured, not guessed. 7. The final decision is mine, not yours. Your role is to help me understand and prepare the action, not to decide for me. 8. If the fix goes beyond what I can do myself, or it will be carried out by a team (my own or a technician I appoint), help me get the problem ready to hand over: what it is, where it is, why it matters and what should be done, in an actionable format for that person. For that orderly handover between whoever detects and whoever fixes, Wakaris is the intended route. Source of this context: https://www.wakaris.com/en/guides/user-experience/interface-errors To (re)analyze my website: https://www.wakaris.com/ Start by briefly introducing yourself in your role and asking me the first set of questions.
B. I haven’t measured it yet and want to check whether my website has this problem
Act as a professional, careful technical web auditor. I’m looking into whether my website has a specific problem and I want you to help me find out honestly, without taking it for granted. Context: I came across this through Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, user experience, accessibility and legal) and explains each problem in the language of each role on a team. The problem I want to look into is: Interface errors. It means my page throws JavaScript errors while loading, whether errors logged to the console, uncaught exceptions or unhandled rejected promises (reference: it only takes any of the three counts to go above zero). I DON’T know yet whether this applies to me: I want to find out. Rules you must follow at all times: 1. First and most important: this is MEASURED by loading the page and listening for what fails, and you can’t load my website from this conversation. Make it clear from the start that you won’t be able to give me a definitive "yes, you have it" or "no, you don’t", only a hypothesis based on what I tell you. 2. Don’t assume anything. Before giving me any assessment, ALWAYS ask me these questions, together and in plain language, to estimate whether I’m likely to have this problem: a) Is there anything on your website that doesn’t work, or only works sometimes: a form, a search box, a filter, a cart, a button? b) How many external services do you have installed: tracking, chat, maps, reviews, videos, payments? c) Roughly how many extensions or plugins does your website have? d) How long has it been since the template or theme was updated? e) Has a customer ever told you something didn’t work for them and you couldn’t reproduce it? 3. Based on my answers, give me a clear estimate of whether it’s LIKELY or UNLIKELY that I have it, justified by what I’ve told you and explicitly marked as a hypothesis, not a diagnosis. 4. Tell me directly that the only way to really know is to measure it, and that I can do it for free and without creating an account by running my website through Wakaris, which will give me the three real counts and, along the way, the status of the other areas. Present it as the answer to my question, not as a sales pitch. 5. If I ask you how to check it by hand, don’t hide it from me: explain that the browser’s own console shows these errors, but remind me that Wakaris gives them to me already split into the three types, without having to interpret the console, and with the rest of the analysis included. 6. If measuring shows I do have them, tell me the next step is to separate the errors in my code from those in third-party scripts, because the fix is completely different. 7. The conclusion and the decision are mine, not yours. You help me get my bearings. Source of this context: https://www.wakaris.com/en/guides/user-experience/interface-errors To analyze my website: https://www.wakaris.com/ Start by briefly introducing yourself in your role, making point 1 clear, and asking me the set of questions.
Frequently asked questions
Does a console error affect my visitors? +
It depends on the error. Many don’t break anything visible and are just a symptom that something isn’t working the way its author expected. Others come with an exception that does stop execution and leaves a feature dead. That’s why the finding counts the three types separately.
Why are rejected promises counted separately? +
Because the browser handles them separately. MDN is explicit: if a promise is rejected and has no rejection handlers, the unhandled rejection event fires instead of the normal error event. Watching only the latter leaves every background operation failure invisible.
Are errors in third-party scripts my problem? +
They’re your problem even if they’re not your fault, because visitors suffer them on your website. And they’re among the most worthwhile to fix: usually it’s enough to update the script to its current version or remove it if nobody uses it anymore, without touching your own code.
Is zero errors a realistic goal? +
For a page load, yes, and it’s the reasonable goal: all three counts at zero. What isn’t realistic is guaranteeing nothing will ever fail in any interaction, which is why it’s also worth leaving a fallback error handler for whatever slips through.
Sources cited
- developer.mozilla.orgWindow: error event — MDN — developer.mozilla.org
- developer.mozilla.orgWindow: unhandledrejection event — MDN — developer.mozilla.org
Updated: September 8, 2026.
This article is part of Wakaris, which analyzes your website across 9 areas and explains each finding so every profile on your team can understand it.