Error Tracking Statistics 2026: Crash Rates, MTTR & Costs
Median crash rate: 1.2%. MTTR: 4.7h. What the data reveals.
The error showed up at 2:47 AM on a Sunday. A TypeError in the checkout flow — Cannot read property 'id' of undefined — that affected 3,200 transactions before anyone noticed. The on-call engineer found out via a customer tweet. Not an alert. A tweet.
That's not unusual. The 2025 PagerDuty State of Incidents report found that 23% of production errors are first reported by customers, not internal monitoring. And here's the kicker: companies without dedicated error tracking tools are 4.1x more likely to learn about critical bugs from Twitter or support tickets than from their own systems. (The same pattern shows up in ad fraud detection — companies discover invalid clicks from billing anomalies, not real-time alerts.)
This post pulls together the actual error tracking statistics for 2026 — crash rate benchmarks, MTTR data, cost modeling, and adoption trends — from Sentry, Rollbar, PagerDuty, Gartner, and the CNCF surveys. If you're trying to justify error tracking tooling to your CFO, benchmark your crash rates against the industry, or understand what "good" looks like, this is the data.
Methodology: Where This Data Comes From
This post compiles publicly available data from: Sentry's 2025 State of Errors report (5.3B sessions analyzed), Rollbar's 2025 Error Intelligence report, PagerDuty's 2025 State of Incidents report, Gartner's 2025 Application Reliability study, and the CNCF 2025 Annual Survey (2,487 respondents).
Limitations: vendor reports are marketing documents, not peer-reviewed research. Sample sizes skew toward companies already using these tools. Cost estimates involve assumptions about hourly rates and downtime impact. Apply appropriate skepticism.
Crash Rate Benchmarks: Median 1.2%, Top Quartile Below 0.5%
The median web application crash rate is 1.2% of sessions. That's the headline number from Sentry's 2025 State of Errors report, which analyzed 5.3 billion sessions across 28,000 production applications.
But medians hide a lot. Here's the distribution:
| Percentile | Web Crash Rate | Mobile Crash Rate |
|---|---|---|
| Top 10% | Below 0.3% | Below 0.8% |
| Top 25% | Below 0.5% | Below 1.2% |
| Median (50%) | 1.2% | 2.1% |
| Bottom 25% | Above 3.2% | Above 4.8% |
| Bottom 10% | Above 6.1% | Above 9.3% |
Mobile crash rates run higher across the board — no surprise there. Device fragmentation, memory constraints, and OS version sprawl make mobile reliability genuinely harder. (If you're monitoring React Native or Flutter apps, our mobile SDK covers the nuances.)
The variance is massive. Top-quartile apps crash at 0.5% or less. Bottom-quartile apps crash six times as often. That's not a tooling difference — it's an engineering culture difference. Teams that treat errors as bugs to fix versus teams that treat errors as noise to ignore.
One thing Sentry's data confirmed that I suspected: crash rates correlate inversely with error tracking adoption. Companies using Sentry, Rollbar, or Bugsnag average 0.9% crash rates. Companies in the dataset without dedicated tooling (tracked via logs and third-party aggregation) average 2.4% crash rates. Correlation isn't causation, but the pattern is consistent.
MTTR: 4.7 Hours Average, 2.3 Hours With Proper Tooling
Mean time to resolution (MTTR) is the metric everyone quotes but few measure accurately. PagerDuty's 2025 report attempted to standardize the measurement: time from first alert to confirmed resolution.
The overall average: 4.7 hours. But that number varies wildly by tooling and team structure:
| Setup | Average MTTR |
|---|---|
| Dedicated error tracking + alerting | 2.3 hours |
| APM/observability platform | 3.1 hours |
| Log aggregation only | 5.8 hours |
| Manual monitoring / customer reports | 11.4 hours |
The gap between "dedicated error tracking" and "log aggregation" is more than double. And the "manual monitoring" category — companies that find out about errors when customers complain — averages nearly 5x longer resolution times.
Look, I've spent entire weekends grep-ing through CloudWatch logs for a single TypeError. It's miserable. You're searching for needles in haystacks, and half the time the needle moved while you were searching. Error tracking tools (Sentry, Rollbar, Bugsnag, and yes, JustAnalytics) give you grouped errors, stack traces, user context, and breadcrumbs. That context is the difference between "where do I even start" and "I see exactly what happened."
Multi-service errors are worse. The same PagerDuty data shows that errors spanning multiple services average 8.2 hours MTTR with tooling — and 19+ hours without. Distributed systems are hard to debug without distributed tracing. (For teams running microservices, the OpenTelemetry integration matters more than the error tracking UI.)
Cost of Unhandled Errors: $1.8M/Year Mid-Market, $4.2M+ Enterprise
Let me be upfront: cost-of-errors statistics are inherently squishy. You're modeling lost revenue from downtime, developer time spent debugging, support escalation costs, and customer churn impact. Lots of assumptions involved.
That said, Gartner's 2025 Application Reliability study attempted a rigorous estimate:
| Company Size | Annual Cost of Unhandled Errors |
|---|---|
| Startups (under 50 employees) | $180K-420K |
| Mid-market (200-1,000 employees) | $1.8M average |
| Enterprise (5,000+ employees) | $4.2M+ average |
The methodology combined: downtime costs ($5,600/minute average across industries), developer debugging time ($150/hour loaded cost), customer support escalations ($45 per ticket average), and estimated churn impact (2.3% of affected users don't return).
Where does that $5,600/minute come from? It's a weighted average from Gartner's survey of 400+ companies. E-commerce runs higher ($9,200/minute during peak hours). B2B SaaS runs lower ($2,100/minute). Financial services runs much higher ($11,000+/minute for trading platforms, and payment processing carries similar stakes). Your actual number depends on your revenue per minute and your user tolerance for errors.
I'll be honest — I think the enterprise number ($4.2M+) is low. That's direct costs only. It doesn't account for engineering morale impact (debugging production fires is demoralizing), technical debt accumulation (hotfixes that never get cleaned up), or brand reputation damage. Stripe famously cited error rates as a key factor in API customer retention — their internal estimates put the cost of error-induced churn significantly higher than external surveys suggest.
For teams tracking where their money goes, the true monthly cost of GA4 + Sentry + Datadog breakdown compares observability stack costs.
Error Volume: Median 47 Unique Errors Per Day
How many errors should you expect? Sentry's dataset provides a baseline:
| Metric | Median | Top Quartile | Bottom Quartile |
|---|---|---|---|
| Unique errors/day | 47 | 12 | 180+ |
| Error events/day | 2,340 | 450 | 8,900+ |
| Errors/user/month | 0.8 | 0.2 | 2.4+ |
"Unique errors" are deduplicated by stack trace — so 47 unique errors generating 2,340 events means each error recurs about 50 times on average. That's typical for web apps: a handful of high-frequency errors (network timeouts, third-party script failures, edge case null pointers) drive most of the volume.
Top-quartile apps run at 12 unique errors per day or fewer. That's remarkably tight. It implies either a mature codebase, aggressive error fixing, or both.
The bottom quartile — 180+ unique errors per day — is basically noise. At that volume, nobody's triaging anything. New errors get buried. Alert fatigue kicks in. The error tracking tool becomes a checkbox, not a workflow. (The fixing noisy error alerts guide covers how to dig out of that hole.)
Error-to-session ratio is the metric I watch most closely. If you're generating 0.8 errors per user per month, most users never see one. At 2.4+ errors per user per month, your average user hits an error every week or two. That's noticeable.
Adoption: 67% of Software Companies Use Error Tracking
The CNCF 2025 survey asked about error tracking specifically. Results:
| Response | % of Respondents |
|---|---|
| Dedicated error tracking tool (Sentry, Rollbar, etc.) | 67% |
| Error tracking bundled in APM/observability platform | 18% |
| Log-based error detection only | 11% |
| No systematic error tracking | 4% |
Two-thirds of companies run dedicated tooling. That's higher than I expected, honestly. And the 18% using bundled APM — that's the Datadog, New Relic, and (yes) JustAnalytics users who get error tracking as part of a larger platform rather than a standalone tool.
The 4% with "no systematic error tracking" aren't all tiny startups. Some are enterprises where different teams have different approaches, and nobody's standardized. Messy, but real.
Adoption by company stage:
| Stage | Dedicated Error Tracking Adoption |
|---|---|
| Pre-seed / bootstrapped | 52% |
| Seed-stage | 68% |
| Series A-B | 84% |
| Series C+ | 89% |
| Enterprise (5K+ employees) | 71% |
The Series A-B spike makes sense — that's when companies hire dedicated infra/platform engineers who bring tooling opinions. The enterprise dip (71% vs. 89% for late-stage startups) reflects the fragmentation problem: different teams, different tools, no single "we use X" answer. (Similar fragmentation shows up in call tracking adoption — marketing uses one platform, sales uses another.)
Resolution Rates: Only 34% of Errors Get Fixed
This stat stung.
Rollbar's 2025 Error Intelligence report tracked error lifecycle data across their customer base: how many errors get marked resolved, how quickly, and what happens to the rest.
34% of unique errors get resolved. The rest either auto-resolve (error stops occurring), get ignored (marked "muted" or "archived"), or sit in backlog limbo indefinitely.
| Error Outcome | % of Unique Errors |
|---|---|
| Resolved (bug fix deployed) | 34% |
| Auto-resolved (stopped recurring) | 28% |
| Muted/archived | 22% |
| Backlog (never triaged) | 16% |
The "auto-resolved" category is interesting. These are errors that spike and then disappear — usually tied to a specific user session, a third-party outage, or a transient network condition. Not worth fixing because they're already gone.
But 22% muted and 16% in backlog? That's 38% of errors that teams decided weren't worth addressing. Some of that is correct prioritization — not every error matters equally. Some of it is triage fatigue — at 180 errors/day, you stop caring. (The error tracking for e-commerce checkout flows post shows how to prioritize errors by revenue impact, not just frequency.)
Source-Map Adoption: 61% of JavaScript Apps
This one's specific to JavaScript (and TypeScript) applications, but it matters.
Source maps let error tracking tools convert minified stack traces back to original code. Without them, you get main.js:1:45032 instead of checkout.tsx:142. The debugging experience difference is massive.
Sentry's data shows: 61% of JavaScript applications sending errors include source maps. That's up from 48% in 2023 — tooling has gotten easier — but 39% still haven't set it up.
| Source Map Status | % of JS Apps |
|---|---|
| Source maps uploaded and working | 61% |
| Source maps configured but broken | 14% |
| No source maps | 25% |
That 14% "configured but broken" is the painful middle ground. Teams that tried to set up source maps, failed, and moved on. Usually it's a CI/CD configuration issue or a mismatch between build versions. (I've been in that 14%. Took me three attempts to get Webpack source maps uploading correctly. Embarrassing? Sure. Common? Apparently.) The how source-map deobfuscation works explainer covers common failure modes.
If you're in the 39% without working source maps, your error tracking ROI is dramatically reduced. You're paying for a tool that shows you minified gibberish. Fix that before worrying about anything else.
Alert Configuration: 73% Use Defaults
Here's another depressing stat.
A 2025 survey from Transcend (privacy infrastructure company) found that 73% of error tracking installations run with default alert configurations. Teams install Sentry or Rollbar, turn on alerts, and never tune them.
Default configurations aren't useless, but they're not optimized for your application:
- Default thresholds trigger on any error increase, regardless of baseline
- Default grouping rules merge unrelated errors or split related ones
- Default notification channels blast everyone instead of routing intelligently
- Default severity levels treat all errors equally
The result: alert fatigue. PagerDuty's data shows teams with untuned alerts average 187 pages/month with only 11 actionable — a 5.9% signal-to-noise ratio. Teams with tuned alerts average 42 pages/month with 29 actionable — a 69% signal-to-noise ratio.
This genuinely frustrates me. Teams pay $400/month for error tracking, don't spend two hours configuring it, then complain the tool is noisy. The tool isn't noisy. The defaults are noisy. There's a difference. If your error alerts feel like noise, they probably are — but the fix isn't fewer errors; it's better configuration. (The release health and regression alerts guide covers deployment-aware alerting.)
Mobile vs. Web: The 1.75x Crash Gap
Mobile apps crash at roughly 1.75x the rate of web apps (2.1% vs. 1.2% median). The gap persists across every industry segment:
| Industry | Web Crash Rate | Mobile Crash Rate | Ratio |
|---|---|---|---|
| E-commerce | 0.9% | 1.6% | 1.8x |
| Fintech | 0.7% | 1.3% | 1.9x |
| Media/Entertainment | 1.4% | 2.4% | 1.7x |
| B2B SaaS | 1.1% | 1.9% | 1.7x |
| Gaming | 1.8% | 3.2% | 1.8x |
Why the gap? Mobile constraints:
- Memory limits — iOS and Android terminate apps that exceed memory thresholds
- Device fragmentation — Android alone has 24,000+ device models with varying specs
- OS version sprawl — supporting iOS 14-18 and Android 10-15 simultaneously
- Network variability — mobile connections drop mid-request more often than desktop
- Background state complexity — app lifecycle on mobile is genuinely harder
Gaming's 1.8% web crash rate (highest web category) and 3.2% mobile crash rate make sense — games push hardware harder than business apps. The fintech 0.7% web crash rate is impressive — but those teams invest heavily in testing because crashes cost real money.
For teams debugging mobile-specific issues, React Native and Flutter monitoring covers platform-specific error patterns.
What These Numbers Mean
Pull back from the individual stats:
-
The bar for "good" is lower than you think. If your crash rate is under 1%, you're above median. Under 0.5%, you're top quartile. Most apps aren't there.
-
Tooling matters for MTTR. The 2.3-hour vs. 5.8-hour gap between error tracking and log-only approaches is real. That's half the debugging time saved — hours that compound across every incident.
-
Most teams don't fix most errors. 34% resolution rate means two-thirds of errors either auto-resolve or get ignored. Some of that's correct prioritization. Some of it's triage fatigue. And honestly? Some of it's just accepting that perfect is the enemy of shipped.
-
Source maps and alert tuning are table stakes. 39% without working source maps and 73% with default alerts means most teams aren't getting full value from tools they're already paying for. This drives me up a wall — but I've also been guilty of it.
-
The cost modeling is squishy but directional. $1.8M/year for mid-market unhandled errors sounds high until you calculate downtime minutes times revenue per minute times engineering hours at loaded cost. The math checks out.
If you're benchmarking your application: check crash rate against the 1.2% median. Check MTTR against the 2.3-hour tooled average. Check error volume against the 47 unique errors/day median. If you're above median on all three, you're doing better than most. For teams building internal tooling, DevOS tracks similar metrics for developer productivity.
Frequently Asked Questions
What is the average crash rate for web applications in 2026?
The median crash rate for web applications is 1.2% of sessions, according to Sentry's 2025 State of Errors report analyzing 5.3 billion sessions. Top-performing applications maintain crash rates below 0.5%, while the bottom quartile exceeds 3.2%. Mobile crash rates trend higher at 2.1% median, largely due to device fragmentation and memory constraints.
How long does it take to resolve production errors on average?
Mean time to resolution (MTTR) for production errors averages 4.7 hours across all industries, per the 2025 PagerDuty State of Incidents report. Teams with dedicated error tracking tools average 2.3 hours — roughly half the time of teams relying on logs alone. The gap widens for complex errors: multi-service issues average 8.2 hours MTTR with tooling versus 19+ hours without.
How much do unhandled errors cost companies annually?
Gartner's 2025 Application Reliability study estimated that unhandled errors cost mid-market companies (200-1,000 employees) an average of $1.8M annually in lost revenue, engineering time, and customer churn. Enterprise companies lose $4.2M+ annually. The calculation includes downtime costs ($5,600/minute average), developer debugging time ($150/hour average), and customer support escalations.
What percentage of companies use dedicated error tracking tools?
67% of software companies use dedicated error tracking tools in production, per the CNCF 2025 Annual Survey. Adoption varies by company stage: 84% of Series B+ startups use error tracking, compared to 52% of bootstrapped companies and 71% of enterprises. The remaining 33% rely on logs, manual monitoring, or customer reports to identify errors.
Try JustAnalytics
All-in-one observability in one under-5KB script: cookieless analytics + error tracking + APM + session replay + uptime + structured logs. Replaces GA4 + Sentry + Datadog + Pingdom + LogRocket. Free tier (100K events/mo), Pro $49/month ($39 annual).
Author at JustAnalytics.