Errors

The Errors page shows you the things that broke for your visitors while they used your site: the script errors their browser ran into, not the ones you see in your own testing. Real people on real devices hit problems you never will, and most of them never tell you. This page is how you find those problems without waiting for a complaint.

Think of it like the check-engine light for your website, except it also tells you how many drivers saw it and lets you replay the exact trip where it lit up.

What you see

• A page title that reads “Errors”, with the date range shown nearby.
• A list of errors, grouped so the same error is counted together instead of listed over and over. The most frequent errors sit at the top. Each row shows the error, how often it happened, and how many different visitors it affected.
• A way into the detail. Open an error to see more about it, including where it happens, and jump from there into a session replay to watch a real visit where it occurred.

How to read it

Start at the top, because the top is where the most people are being hurt.

Here is a worked example. Say the top error affected 800 visitors this week and happens on your checkout page. A rare error near the bottom affected 3 visitors on a page almost nobody visits. Which do you fix first? The top one, without question. It is not about which error looks scary in the text, it is about how many real people it is costing you and where. An error on checkout that hits hundreds of people is an emergency. A rare error on a quiet page can wait.

Counting by affected visitors, not just by raw occurrences, matters. One visitor stuck in a loop can trigger the same error hundreds of times. Reading affected visitors tells you how many people actually felt it.

Customize it

• Set the date range. Use a short range to check whether something you just shipped introduced a new error, and a longer range to see the errors that have been quietly bothering people for a while.
• Scope to one website. If you track more than one site, narrow the list so one site’s errors are not mixed with another’s.
• Open an error, then a replay. Click into the error that matters, then watch a real session where it happened. Watching a replay is part of the Pro and Business plans; it turns “an error happened somewhere” into “here is exactly what the visitor did right before it broke.”

Use cases

• Catch a bad release fast. Right after you ship a change, set the range to the last day and watch for a new error climbing the list. Action: if a fresh error appears and spreads, you have a regression, so roll back or fix it before more people hit it.
• Fix what hurts the most people. Sort your attention by affected visitors and start at the top. Action: fix the errors that touch the most people on your most important pages first, then work down.
• Understand a confusing bug report. A visitor says something broke but cannot explain it. Action: find the matching error, open a replay, and watch the exact steps, so you fix the real cause instead of guessing.

Tips

• Frequency and affected visitors are different. A high count from one stuck visitor is less urgent than a lower count spread across many people. Read both.
• Not every error is worth fixing. Some come from browser extensions or third-party scripts you do not control. Focus on the ones on your own important pages that affect real numbers of people.
• The replay is where the fix lives. The list tells you what broke and how often. Watching a real session tells you why, which is what actually lets you fix it.
• A quiet Errors page is good news, not a broken page. If nothing shows and your site is busy, that usually means things are working.