How to Set a Crash-Free Rate Target for Launch

Every launch needs a stability number you can point at, and crash-free rate is the one most teams settle on. It compresses a messy reality, thousands of sessions across many devices, into a single percentage that says how often players get through without a crash. But the number is only useful if it is defined precisely and the target is chosen deliberately. A vague crash-free goal is just a wish. This post covers defining the metric exactly, picking a bar you can defend, and wiring it into your launch decision so it actually gates the release.

What crash-free rate measures

Crash-free rate is the proportion of some unit, sessions or users, that completed without experiencing a crash. Crash-free sessions counts each play session and asks whether it ended in a crash. Crash-free users counts each player and asks whether they hit any crash across all their sessions in the window. The two answer different questions: sessions reflect raw stability per play, while users reflect how many people were affected at all, which is usually the lower and more sobering number.

Choosing between them is the first real decision. Crash-free sessions is the more common headline because it scales naturally with playtime and is easy to reason about. Crash-free users is harsher and more player-centric, because one unlucky player who crashes once counts against you for the whole window. Many teams track both and lead with sessions for the public-facing number while watching users internally. Whatever you pick, define it once and stick to it, because comparing across inconsistent definitions is meaningless.

Defining the metric precisely

A crash-free rate is only trustworthy if everyone agrees on its inputs. Decide what counts as a crash: native crashes clearly do, but what about ANRs, handled exceptions that degrade the experience, or soft hangs? Pick a definition and document it, because a rate that silently excludes freezes will look better than the player experience actually is. Decide the measurement window too, since a rate over the first launch day reads very differently from a rolling thirty-day rate.

Sampling and session definition matter as well. Be clear about what starts and ends a session, especially for a game that players leave running or background frequently. If your SDK only reports from a subset of players, understand that your rate is an estimate, and that crashes which prevent reporting can bias it optimistically. Writing these choices down turns crash-free rate from a number people argue about into a number people trust, which is the entire point of having a metric.

Choosing a defensible bar

The right target depends on your genre, audience, and platform, so resist copying a number off a slide. A fast session arcade game and a long-session strategy game tolerate crashes very differently, and a high crash-free session rate that sounds great can still mean an unacceptable share of affected users. Start from what your players will actually tolerate, look at where comparable titles in your category sit, and set a bar that is ambitious but reachable rather than a round number nobody can hit.

A defensible bar is also one you can sustain, not just clear once. A target you only meet by freezing all changes is not a launch bar, it is a snapshot. Pick a level you can hold as you keep shipping updates, and define how you will respond when you miss it. The number itself matters less than the agreement that falling below it triggers action, because a target with no consequence is just decoration on a dashboard.

Using the target as a gate

A crash-free target earns its keep when it gates decisions. Before launch, treat the bar as a go or no-go condition: if your beta or soft-launch crash-free rate is below it, you delay, hotfix, or cut the offending feature rather than ship on schedule. After launch, treat a drop below the bar as an incident that warrants a hotfix, the same way you would treat a sudden crash spike. The metric only changes behavior if it has teeth.

To gate well, watch the rate continuously rather than checking it once. A crash-free rate that looks fine at launch can sag as a problematic build reaches more players, so you want the number trending live, ideally broken down by build and platform. That breakdown tells you not just that you missed the bar but where, so a single bad platform does not get hidden behind a healthy overall average. A gate you can see through is far more useful than a single end-of-day figure.

Setting it up with Bugnet

Bugnet gives you the raw material for a crash-free rate by capturing crashes through its SDK along with session and player context, so you can compute the share of sessions or users that stayed crash-free. Because every crash carries its build and platform, you can break the rate down by release and device, which is exactly the view you need to gate a launch. A drop concentrated in one build or one platform shows up immediately instead of hiding inside an aggregate number.

Occurrence grouping helps you act on the rate rather than just watch it fall. When crash-free rate dips, Bugnet shows you which grouped signatures are driving it, ranked by occurrence count, so you know which crashes to fix to recover the metric fastest. You can filter by build to confirm a regression, track the rate as a fixed build rolls out, and tag the issues threatening your launch bar, all from one dashboard that ties the headline number to the specific crashes behind it.

Living with the metric after launch

A crash-free target is not just a launch gate, it is an ongoing health signal. Keep watching it after release, set an alert for when it drops below your bar, and review it as a standing part of your post-launch routine. Over time you will learn what normal looks like for your game, which makes a real regression obvious against the baseline. The goal is not a perfect number but a stable, well-understood one that you notice when it moves.

Be honest about the metric's limits too. A high crash-free rate can still hide a small group of players who crash constantly, and it says nothing about non-crash bugs that ruin the experience. Pair it with the harsher crash-free users figure and with qualitative player reports so you see the whole picture. Used this way, crash-free rate is a sharp, defensible launch bar and a reliable ongoing pulse, not a vanity number you point at and forget.

Crash-free rate is only a real bar if it is defined precisely and has teeth. Define it, pick a defensible target, and let it gate the launch.