Error Monitoring
Every broken button, failed form, and JavaScript crash is a conversion you may never recover. Error monitoring gives you visibility into what's breaking on your website before users complain — or leave.
This guide covers the full scope of error monitoring for websites: what to track, how to prioritize, and how to connect technical problems to business impact.
Contents
- What error monitoring actually means
- Types of errors to track
- The error monitoring stack
- Connecting errors to conversions
- User behavior signals
- Prioritizing what to fix
- Common mistakes
- Frequently asked questions
What error monitoring actually means
Error monitoring is the practice of automatically detecting, capturing, and organizing problems that occur on your website. When something breaks — a JavaScript exception, a failed API call, a 404 page — an error monitoring system records it with enough context to understand what happened and who was affected.
The goal is not just to know that errors exist. It's to understand which errors matter and fix them before they cost you conversions.
| Without error monitoring | With error monitoring |
|---|---|
| Users hit errors silently | Errors captured automatically |
| Problems discovered via complaints | Problems discovered in real-time |
| No context on what happened | Full context: page, browser, user journey |
| Guessing which errors matter | Errors ranked by business impact |
| Fixes prioritized by gut feel | Fixes prioritized by data |
Error monitoring is not the same as uptime monitoring. Uptime tells you if your site is reachable. Error monitoring tells you if your site is working correctly for the users who reach it.
Types of errors to track
Website errors fall into several categories, each requiring different detection methods.
JavaScript errors
These are runtime exceptions in your frontend code. A TypeError, ReferenceError, or any unhandled exception that fires in the browser. JavaScript errors can completely break interactive features — forms that won't submit, buttons that don't respond, pages that fail to render.
Common causes include:
- Undefined variables or null references
- Failed API calls that weren't handled
- Browser compatibility issues
- Third-party script conflicts
- Race conditions during page load
Network failures
API calls that fail, images that don't load, scripts that timeout. These are HTTP requests that return error status codes (4xx, 5xx) or fail entirely due to network issues.
Network failures often indicate:
- Backend service problems
- CDN configuration issues
- Third-party service outages
- CORS misconfigurations
404 errors
Broken links and missing pages. Every 404 is a dead end for users and a signal to search engines that your site has structural problems. 404s from internal links are especially important — they indicate bugs in your code or content, not just external sites linking incorrectly.
Silent failures
Not all problems throw errors. A button with href="#" works perfectly from the browser's perspective — it just does nothing useful. These silent failures require behavioral signals like rage clicks to detect.
The error monitoring stack
A complete error monitoring setup combines multiple tools and techniques.
| Layer | What it catches | Example tools |
|---|---|---|
| JavaScript error tracking | Frontend exceptions | Sentry, Datadog RUM, askbowtie |
| Network monitoring | Failed requests, slow APIs | Browser DevTools, monitoring tools |
| Uptime monitoring | Site availability | Pingdom, UptimeRobot, askbowtie |
| Log aggregation | Backend errors | Datadog, Logtail, CloudWatch |
| Behavioral monitoring | Silent failures, user frustration | Hotjar, FullStory, askbowtie |
Most website owners don't need every layer. If you run a WordPress site or Shopify store, frontend error tracking combined with uptime monitoring covers the majority of problems you can actually fix.
For a detailed comparison of error monitoring tools, see Error Monitoring Tools Compared.
Connecting errors to conversions
Error monitoring becomes valuable when you connect technical problems to business outcomes. An error that fires 10,000 times on your blog matters less than one that fires 50 times on your checkout page.
The key question: How many conversions did this error cost?
To answer this, you need:
- Error tracking — Know which errors occur and on which pages
- Session tracking — Know which users encountered each error
- Conversion tracking — Know which sessions converted
- Correlation — Compare conversion rates between error sessions and clean sessions
| Scenario | Error frequency | Conversion impact | Priority |
|---|---|---|---|
| Blog animation error | 8,400/week | Zero — decorative element | Low |
| Checkout form error | 73/week | 60% conversion drop | Critical |
| Product image 404 | 200/week | 15% conversion drop | High |
| Admin panel bug | 150/week | No conversion path | Low |
This framework is covered in depth in Prioritizing Errors by Revenue Impact.
When error monitoring is connected to conversion data, you stop asking "which error fired the most?" and start asking "which error costs the most?" The fixes that matter become obvious.
User behavior signals
Technical errors are only half the picture. User behavior tells you when something is broken even if no error fires.
Rage clicks
When a user rapidly clicks the same element 3 or more times, something isn't responding. Rage clicks indicate frustration — a button that doesn't work, a link that goes nowhere, a form that won't submit.
Rage clicks catch problems that traditional error monitoring misses: placeholder links, broken event handlers, elements that look clickable but aren't. See the full guide on understanding rage clicks.
Dead clicks
Clicks on non-interactive elements. Users expect something to happen, nothing does. Dead clicks often indicate unclear UI or missing functionality.
Session context
Understanding what users were doing before an error provides debugging context. Did they come from a paid ad? Were they on mobile? Did they encounter other errors in the same session? This context helps prioritize and diagnose issues.
For a deeper exploration of behavioral signals, see the User Behavior sub-pillar.
Prioritizing what to fix
The default instinct is to fix the most frequent errors first. This is wrong.
Frequency tells you how loud a problem is. It doesn't tell you how expensive it is. A framework for prioritizing errors by actual impact:
1. Where does it fire? Errors on checkout, pricing, and signup pages have direct revenue impact. Errors on blog posts and documentation pages are lower priority.
2. What does it block? Blocking errors prevent users from completing their task. Non-blocking errors are visible in the console but invisible to users.
3. Who does it affect? Errors affecting paid traffic are more expensive than those affecting organic blog readers. You paid to acquire those users.
4. What's the conversion rate gap? Compare conversion rates between sessions that encountered the error and sessions that didn't. This gives you a dollar figure.
The detailed framework: Not All JavaScript Errors Are Equal.
Common mistakes
These patterns repeatedly cause teams to miss important errors or waste time on unimportant ones.
Sorting by frequency instead of impact. The most common error is rarely the most expensive. Sort by conversion impact, not occurrence count.
Ignoring silent failures. Not everything broken throws an error. Placeholder links, broken handlers, and conditional logic that fails silently all need behavioral signals to detect.
No noise filtering. Browser extension errors, third-party script failures, and bot traffic create noise that buries real problems. Filter these out before triaging.
Disconnected tools. Error tracking in one tool, analytics in another, conversion tracking in a third. The correlation between errors and business impact requires connecting these data sources.
Treating all pages equally. An error on your checkout page is not the same severity as an error on your terms of service page. Map errors to pages and prioritize accordingly.
Fixing errors instead of preventing them. Good error handling catches problems before they reach users. Input validation, loading states, and graceful degradation prevent many errors from occurring at all.
Frequently asked questions
How many errors is normal?
It depends entirely on your traffic and site complexity. A small brochure site might have zero JavaScript errors. A complex web application might have thousands daily. The question isn't "how many errors do I have?" but "are my errors trending up or down, and are the important ones being fixed?"
Should I track backend errors too?
If you control your backend, yes. Backend errors (500 responses, unhandled exceptions) affect users just as much as frontend errors. However, if you're using a managed platform like Shopify or Squarespace, backend monitoring isn't available to you — focus on what you can control.
What's the difference between error monitoring and APM?
Application Performance Monitoring (APM) is broader. It includes error tracking but also covers performance profiling, distributed tracing, and infrastructure monitoring. Error monitoring focuses specifically on catching and diagnosing failures. For most websites, error monitoring is sufficient. APM becomes valuable when you have complex backend systems to debug.
How do I filter out noise from third-party scripts?
Most error monitoring tools let you configure ignore rules for specific domains or error patterns. Filter errors from chrome-extension://, third-party analytics scripts, and bot traffic. A good noise filter can reduce your error count by 90% while keeping the errors you can actually fix.
Do I need error monitoring if I have uptime monitoring?
Yes. Uptime monitoring tells you if your site is reachable. It doesn't tell you if your site works correctly. Your checkout can be completely broken while uptime shows 100%. Error monitoring catches functional problems that uptime monitoring misses.
Sub-pillars
User Behavior Signals
Rage clicks, dead clicks, and session context — the signals that reveal what errors don't.
Error Monitoring Tools
Overview of the tool landscape and how to choose the right one for your situation.
Next steps
If you're new to error monitoring:
- Start with Understanding Rage Clicks to see how silent failures work
- Learn the prioritization framework for ranking errors by impact
- Compare error monitoring tools to find the right fit
If you're already tracking errors:
- Explore user behavior signals to catch what error tracking misses
- Connect your error data to conversion tracking for revenue impact analysis
- Consider performance monitoring to catch slowness before it becomes errors