Monitoring Game Stability Metrics: Crash-Free Sessions, MTTR, and More

Tracking the right game stability metrics crash free sessions helps you measure what matters. You shipped a new content update, the Steam reviews are rolling in, and then you notice a spike in crash reports. Players are not complaining about missing features — they are complaining that the game will not stay open long enough to experience them. After launch, game stability metrics matter more than feature metrics. A game that crashes is a game that gets refunded. Here is how to measure stability, set targets, and use data to decide when your build is ready to ship.

Why Stability Metrics Matter More Than Feature Metrics Post-Launch

Feature completion gets you to launch day. Stability keeps you there. A player who encounters a crash in their first session has a roughly 70% chance of never returning, according to industry data from mobile and PC analytics platforms. Compare that to a missing feature, which players will typically request and wait for. Crashes are silent killers of retention and revenue.

Game performance monitoring is not just about frame rates and load times. The most important signal is whether sessions complete without a fatal error. That single number — the crash-free session rate — tells you more about player experience than any feature dashboard ever will.

The Five Metrics Every Game Studio Should Track

1. Crash-Free Session Rate

This is the north star of game reliability. It measures the percentage of all play sessions that complete without a crash or unhandled fatal error.

Crash-Free Session Rate = (1 - (Crashed Sessions / Total Sessions)) * 100

Example: Your game logged 50,000 sessions this week. 200 of them ended in a crash. Your crash-free session rate is (1 - 200/50,000) * 100 = 99.6%. That is above the 99.5% target — you are in good shape.

The target for production games is 99.5% or higher. Anything below 99% should be treated as a release-blocking issue. Below 95% is a crisis that warrants pausing feature work entirely.

2. Crash-Free User Rate

This metric is different from the session rate because it measures unique affected players rather than individual sessions. A single power user who plays 50 sessions and crashes twice counts as one affected user, but those two crashed sessions are diluted across their 50 total sessions.

Crash-Free User Rate = (1 - (Users With At Least One Crash / Total Active Users)) * 100

Example: You have 8,000 active players this week. 320 of them experienced at least one crash. Your crash-free user rate is (1 - 320/8,000) * 100 = 96.0%. Notice this is significantly lower than the session rate. That is typical — crash-free user rate is almost always lower because players with many sessions are statistically more likely to hit at least one crash.

Use this metric alongside the session rate. If your session rate is 99.5% but your user rate is only 90%, you have a problem that affects a wide pool of players, even if each individual player rarely crashes. That pattern often points to a crash that is triggered by a common but not universal hardware configuration or OS version.

3. Mean Time to Resolution (MTTR)

MTTR measures the elapsed time from when the first crash report for an issue arrives to when a fix is deployed to players. This is the metric that separates studios that respond to crashes from studios that fix them.

MTTR = Sum of (Fix Deployed Time - First Report Time) for All Resolved Issues / Number of Resolved Issues

Example: This week you resolved four crash issues with resolution times of 2 hours, 5 hours, 8 hours, and 1 hour. Your MTTR is (2 + 5 + 8 + 1) / 4 = 4 hours. For an indie studio, an MTTR under 24 hours for critical crashes is a strong target. AAA studios with live-service games often aim for under 4 hours.

Track MTTR by severity. A critical crash affecting 10% of players needs a different response time than a rare edge-case crash affecting 0.01%. Breaking MTTR into tiers — P0 (under 4 hours), P1 (under 24 hours), P2 (under 1 week) — gives your team clear escalation guidelines.

4. Regression Rate

A regression is a bug fix that introduces a new crash. Regression rate measures how often your fixes make things worse.

Regression Rate = (Fixes That Introduced New Crashes / Total Fixes Deployed) * 100

Example: You shipped 12 crash fixes this month. Two of them caused new crashes that were reported within 48 hours of deployment. Your regression rate is (2/12) * 100 = 16.7%. That is too high. A healthy regression rate is under 5%, which means fewer than 1 in 20 fixes creates a new problem.

High regression rates usually point to insufficient testing, missing integration tests around crash-prone systems (save/load, scene transitions, network reconnection), or fixes that are applied too hastily under pressure. If your regression rate climbs above 10%, slow down your fix cadence and add a staging or canary release step.

5. Error Budget

An error budget is borrowed from site reliability engineering (SRE) and answers a simple question: how many crashes are acceptable in a given time period? It converts your crash-free target into an absolute number.

Daily Error Budget = Total Daily Sessions * (1 - Target Crash-Free Rate)

Example: Your game averages 10,000 sessions per day. Your target crash-free session rate is 99.5%. Your daily error budget is 10,000 * (1 - 0.995) = 50 crashes per day. If you are burning through fewer than 50 crashes, you have budget remaining to ship new features. If you are exceeding 50, all engineering effort should go toward stability.

Error budgets create a shared language between developers and producers. Instead of debating whether stability is "good enough," you can point to a concrete number. If the budget is spent, feature work pauses. This prevents the common pattern where stability degrades slowly across releases because no single update seems "bad enough" to address.

Setting Up Dashboards and Alerts

Metrics only matter if someone is looking at them. Build a stability dashboard that shows crash-free session rate, crash-free user rate, and MTTR on a rolling 7-day window. Include a daily trend line so you can spot regressions immediately after a patch.

Spike detection: Set up an alert that fires when crash volume in any 1-hour window exceeds 3x the rolling average for that hour over the past 7 days. This catches sudden regressions from hotfixes or server-side changes without triggering false positives from normal daily traffic patterns.

Threshold alerts: Configure a persistent alert when crash-free session rate drops below your target (e.g., 99.5%) for more than 2 consecutive hours. This filters out brief transient spikes and focuses your attention on sustained degradations that are actually affecting player experience.

Error budget burn rate: Track how quickly you are consuming your daily error budget. If you burn through 80% of your daily budget in the first 4 hours after a patch, that is a strong signal to roll back before the full impact hits your player base.

Using Stability Metrics to Decide Release Readiness

Before every release, run a release readiness check against your stability gate criteria. A simple framework that works for indie studios:

Green light: Crash-free session rate above 99.5%, MTTR under 24 hours for the past sprint, regression rate under 5%, error budget has remaining capacity. Ship the release.

Yellow light: Crash-free session rate between 99.0% and 99.5%, or MTTR trending upward. Ship only if the release contains stability fixes. Delay feature-only releases until metrics recover.

Red light: Crash-free session rate below 99.0%, or error budget exhausted, or regression rate above 10%. Do not ship. All engineering effort goes to stability until the metrics are back in the green zone.

Benchmarks: The 95% to 99.5% Journey

Most indie games launch with a crash-free session rate between 95% and 97%. That sounds acceptable until you do the math: at 95%, one in every twenty sessions crashes. A player who plays five sessions a day will crash once daily. That adds up fast in reviews and refund requests.

The typical improvement journey looks like this:

95% to 97% — Fix the top 3 crash signatures. These usually account for 60-70% of all crashes and are often null reference errors, out-of-memory conditions on low-end hardware, or unhandled exceptions in save/load code. This phase typically takes 1-2 weeks.

97% to 99% — Address platform-specific crashes (specific GPU drivers, OS versions, input devices). Add crash grouping and deduplication so you can prioritize by impact. This phase takes 2-4 weeks and requires more instrumentation.

99% to 99.5%+ — Hunt down rare race conditions, memory leaks that only manifest in long sessions (4+ hours), and edge cases in mod support or user-generated content. This phase is ongoing and requires systematic monitoring rather than reactive firefighting.

"Ship your first patch for stability, not for features. Players forgive missing content. They do not forgive a game that crashes during the final boss fight."

How Bugnet Tracks These Automatically

Bugnet's analytics dashboard calculates crash-free session rate, crash-free user rate, and MTTR from the crash reports and session data flowing through the SDK. When a crash report comes in, Bugnet groups it by stack trace signature, links it to the affected session and user, and updates your stability metrics in real time. You can set threshold alerts directly in the dashboard and receive notifications via Discord webhook or email when your error budget is at risk. No spreadsheet math required — just integrate the SDK and start tracking from day one.

Related Issues

If you are seeing crashes spike after deploying new builds, our guide on automating bug tracking in your CI/CD pipeline covers how to catch regressions before they reach players. If your crash-free rate is low specifically on mobile platforms, the mobile crash debugging guide walks through platform-specific tools and common pitfalls.

Track the metrics that matter. Your players cannot file a bug report if the game crashes before they can reach the menu.