Quick answer: A healthy game should maintain a crash-free session rate of 99.5% or higher, meaning fewer than 1 in 200 play sessions experience a crash. Rates between 99% and 99.5% indicate room for improvement.

This guide covers crash free session rate what it means for games in detail. Every game crashes sometimes. The question is not whether it happens, but how often. The crash-free session rate gives you a single number that answers that question: what percentage of play sessions complete without a crash? It is the most important stability metric for a shipped game, and understanding it — how to calculate it, what good looks like, and how to improve it — is essential for maintaining a healthy game post-launch.

Defining the Metric

The crash-free session rate is calculated as:

# Crash-free session rate formula

crash_free_rate = (total_sessions - crashed_sessions) / total_sessions * 100

# Example:
# 10,000 total sessions today
# 42 sessions experienced at least one crash

rate = (10000 - 42) / 10000 * 100
rate = 99.58%

A session starts when the game process launches and ends when the player quits normally (through the menu, Alt+F4, or closing the window). If the game process terminates abnormally — a segfault, an unhandled exception, a force kill by the OS — that session is counted as a crash.

Two important nuances. First, if a player experiences two crashes in two separate sessions on the same day, those count as two crashed sessions out of two total sessions. Second, a session where the player force-quits via Task Manager is technically an abnormal termination, but most crash reporting systems distinguish between an unhandled exception (a crash) and a clean process kill (the player closing the game). Only the former counts as a crash.

What Good Looks Like

Crash-free rate benchmarks vary by platform and game type, but general guidelines apply across most indie games.

# Crash-free session rate benchmarks for games

99.8%+   Excellent. Very stable game. Remaining crashes are
         likely hardware-specific edge cases.

99.5%    Good. Industry standard for a well-maintained game.
         About 1 in 200 sessions crash.

99.0%    Needs work. 1 in 100 sessions crash. Players will
         notice and mention it in reviews.

98.0%    Problematic. 1 in 50 sessions crash. Expect negative
         reviews specifically about crashes.

95.0%    Critical. 1 in 20 sessions crash. This is an emergency
         requiring immediate hotfixes.

<95%     Broken. Consider pulling the release and fixing before
         continuing to sell the game.

These benchmarks assume a typical desktop game. Mobile games, due to the extreme diversity of hardware and OS versions, often have slightly lower rates, with 99% considered acceptable. Console games, with their standardized hardware, should achieve higher rates — 99.8% or better is expected by platform holders.

Crash-Free Sessions vs. Crash-Free Users

The crash-free session rate and the crash-free user rate are related but different metrics, and confusing them leads to incorrect conclusions.

The session rate answers: “If I start a new play session right now, what is the probability it will crash?” This is the most useful metric for understanding the player experience moment to moment.

The user rate answers: “Over the past week, what percentage of unique players experienced zero crashes?” This metric is useful for understanding total player impact, but it can be misleading. A player who plays 50 sessions a week is far more likely to encounter at least one crash than a player who plays twice, even if the per-session crash probability is identical.

# Illustrating the difference between session and user rates

# Player A: Plays 50 sessions/week
# Player B: Plays 2 sessions/week
# Game has 99.5% crash-free session rate

# Probability of Player A having zero crashes in a week:
P(no crash) = 0.995 ^ 50 = 77.8%
# Player A has a 22.2% chance of experiencing at least one crash

# Probability of Player B having zero crashes in a week:
P(no crash) = 0.995 ^ 2 = 99.0%
# Player B has only a 1% chance of experiencing a crash

# Both experience the same per-session stability,
# but their weekly user-level experience is very different.

This is why the session rate is more actionable than the user rate. It measures the thing you can actually improve (the probability of a crash per session) without being confounded by how often different players play.

Why the Number Matters More Than You Think

The crash-free rate has a nonlinear relationship with player perception. Moving from 99% to 99.5% sounds like a tiny improvement — half a percentage point. But it means cutting your crash count in half. A player who used to crash once every 100 sessions now crashes once every 200. Over a month of daily play, that is the difference between crashing three times and crashing once or not at all.

The relationship between crash rate and negative reviews is also nonlinear. Below 99%, crashes become common enough that a meaningful percentage of players mention them in reviews. Above 99.5%, crashes are rare enough that most players never experience one, and those who do chalk it up to bad luck rather than a buggy game. The half-percent between 99% and 99.5% is the difference between “this game is buggy” and “I had one crash but otherwise it’s fine.”

“A 99% crash-free rate sounds great until you realize it means 1 in 100 sessions crash. If your game has 10,000 daily sessions, that is 100 crashes per day. One hundred players, every day, having their experience interrupted.”

Improving Your Crash-Free Rate

Improving the crash-free rate is a focused exercise. You do not need to fix every bug — you need to fix the bugs that crash the most players. Crash reports follow a power law distribution: a small number of unique crash signatures account for the vast majority of crash occurrences.

Step 1: Rank crash signatures by volume. Sort your unique crashes by how many times each has occurred. The top 3-5 crashes almost always account for 60-80% of total crash volume. These are your targets.

Step 2: Fix the highest-volume crash. Investigate, reproduce, fix, and ship a patch. Do not bundle this with feature work or other changes. A focused stability patch makes it easy to verify that the fix worked.

Step 3: Measure the impact. After the patch has been live for 48 hours, compare the crash-free rate to the pre-patch baseline. Did it improve? By how much? Is the specific crash signature still occurring (indicating the fix was incomplete) or has it disappeared?

Step 4: Repeat. Move to the next highest-volume crash. Each fix improves the overall rate, and the improvement is visible in the metric. This creates a positive feedback loop where stability improvements are measurable and motivating.

# Example: Impact of fixing top crashes on crash-free rate

# Before any fixes:
Total daily sessions:  10,000
Total daily crashes:   150
Crash-free rate:       98.5%

# Crash #1 (null ref in SaveSystem): 65 occurrences/day
# Crash #2 (shader compile on Intel): 40 occurrences/day
# Crash #3 (OOM on 4GB RAM systems): 25 occurrences/day
# All other crashes: 20 occurrences/day

# After fixing crash #1:
Crashes: 150 - 65 = 85
Rate:   99.15%  (+0.65%)

# After also fixing crash #2:
Crashes: 85 - 40 = 45
Rate:   99.55%  (+0.40%)

# After also fixing crash #3:
Crashes: 45 - 25 = 20
Rate:   99.80%  (+0.25%)

# Three fixes took us from 98.5% to 99.8% — from "needs work" to "excellent"

Alerting on Regressions

Once you have improved your crash-free rate, you need to protect it. Every patch and update risks introducing new crashes that undo your work. Regression alerts are the safety net.

Set an alert threshold slightly below your current rate. If your game is at 99.6%, set an alert at 99.3%. This gives you a margin for natural daily variation (the rate will fluctuate by a fraction of a percent day to day) while catching genuine regressions that drop the rate by a meaningful amount.

Bugnet’s game health dashboard tracks crash-free rate automatically and can send notifications to Discord, Slack, or email when the rate drops below your configured threshold. Combined with version tagging on crash reports, this gives you immediate visibility into whether a new release is causing problems.

Beyond the Number

The crash-free rate is your headline metric, but it does not tell the whole story. A game can have a 99.8% crash-free rate and still have serious stability issues if the crashes are concentrated on a specific platform, affecting a specific player action, or hitting a specific hardware configuration.

Segment your crash-free rate by platform, by game version, and by hardware configuration. A 99.8% overall rate might hide a 95% rate on Linux or a 97% rate on machines with less than 8 GB of RAM. These segmented rates reveal problems that the aggregate obscures.

Track session length alongside the crash-free rate. If your average session length is dropping while the crash-free rate stays constant, players might be experiencing non-crash issues (freezes, performance problems, soft locks) that cause them to quit voluntarily but are not captured as crashes.

Related Issues

For a complete guide to stability metrics beyond crash-free rate, see game stability metrics and crash-free sessions. To learn how to improve your rate before launch, read how to reduce your game’s crash rate before launch. And for setting up the monitoring infrastructure that tracks this metric, see how to monitor game stability after launch.

Your crash-free rate is the one number that tells you whether your game is getting better or worse. Track it, improve it, protect it.