Should I rank by total crashes or by players affected?

Rank primarily by distinct players affected. Total occurrences can be inflated by a single player who hit the same crash repeatedly in a loop, which makes a narrow issue look broad. Players affected reflects true reach across your install base, so it is the better primary sort, with total occurrences as a secondary tiebreaker.

What crash-free rate should I aim for?

Higher is always better, but the more useful target is steady upward movement after each hotfix rather than a fixed number. If your crash-free sessions sit in the low nineties, roughly one in ten or twelve sessions ends in a crash, which is a meaningful leak. Use the trend to confirm your fixes are hitting the dominant crashes.

When does a rare crash deserve priority over a common one?

When its cost per occurrence is severe. A crash that corrupts saves or wipes an hour of progress can outrank a frequent but harmless menu glitch, because each occurrence does lasting damage and is far more likely to make a player quit. Weight crashes by where in the session they land, not by frequency alone.

Using Crash Data To Decide What To Fix First

Quick answer: When several crashes hit at once, fix the one affecting the most players first. Rank crashes by occurrence count and by how many distinct players they touch, watch your crash-free rate to gauge overall health, and weigh severity by where in the session the crash lands. Data turns a panicked triage into an ordered list.

After a launch or a big update, the crash reports rarely arrive one at a time. You get a dozen different stack traces in an afternoon and a sinking feeling that the whole thing is on fire. The instinct is to fix whatever you saw last or whatever looks scariest, but that instinct is usually wrong. Crash data, read properly, tells you exactly which crash to fix first: the one hurting the most players, the most. This post walks through occurrence counts, crash-free rate, and impact weighting so your next hotfix targets the bug that matters instead of the bug that happened to be loudest.

Why gut feel fails during a crash storm

During a crash storm your sense of priority gets hijacked by recency and vividness. The crash a streamer hit on camera feels urgent because you watched it happen, even if it affects a tiny fraction of players. A scary-looking null dereference in core code feels important even if it fires once a day. Meanwhile a boring, frequent crash on a specific device quietly ends sessions for hundreds of people and never grabs your attention because no single report stood out. Gut feel optimizes for drama, not for reach.

The fix is to let the numbers rank the work and reserve judgment for the edge cases. Crash data gives you two things gut feel cannot: how many times a crash fired, and how many distinct players it touched. Those two figures cut through the drama immediately. A crash with a high player count is hurting your install base whether or not anyone made noise about it, and that is the crash that should jump to the front of your hotfix queue before you spend a day chasing the cinematic one.

Occurrence counts and players affected

The single most useful number in crash triage is the count of distinct players a crash touched. Total occurrences matter too, but they can be skewed by one unlucky player who hit the same crash forty times in a loop. Distinct players affected tells you the true reach: a crash hitting three hundred different people is a population problem, while one hitting three people who each retried a lot is a sharp edge for a few. Rank primarily by players affected and you will rarely fix the wrong thing.

Grouping is what makes those counts trustworthy. If the same crash arrives as forty separate reports, no count is visible and every report looks equally minor. Fold them into one issue with a running tally and the heavy hitters announce themselves. The crash at the top of a players-affected ranking is, almost by definition, the one whose fix buys back the most player experience per hour of engineering. Start there, ship it, then re-sort, because the ranking shifts the moment you remove the biggest item from the board.

Crash-free rate as your health gauge

Individual crash counts tell you what to fix; crash-free rate tells you whether you are winning overall. It is the share of sessions or players that completed without a crash, and it is the number to watch across a release. If your crash-free sessions sit at ninety-two percent, roughly one in twelve play sessions ends badly, which is a serious leak for a game asking people to invest hours. Tracking this single percentage over time turns a fog of individual reports into a clear signal of whether your stability is improving.

Use crash-free rate to set a bar and to know when to stop firefighting. After a hotfix, the rate should climb; if it does not, the crash you fixed was not the dominant one and you should re-check your ranking. Watching the rate also protects you from declaring victory too early, because a single dramatic fix can feel like progress while the aggregate barely moves. The goal is steady upward movement in crash-free rate, driven by repeatedly fixing whatever sits at the top of your players-affected list.

Weighting by where the crash lands

Not all crashes cost the same even at equal frequency. A crash on the title screen is annoying but cheap; the player relaunches and loses nothing. A crash during a boss fight or right before an autosave can wipe out an hour of progress and is far more likely to make someone quit for good. When you rank crashes, layer a severity weight on top of the player count that reflects where in the session the crash lands and how much it destroys when it fires.

This weighting occasionally promotes a lower-frequency crash above a higher-frequency one, and that is correct. A save-corruption crash hitting fifty players deserves to outrank a harmless menu flicker hitting two hundred, because the cost per occurrence is brutal. Capturing the game state and the point in the session at the moment of the crash is what lets you apply this weighting honestly, instead of guessing how bad each one feels. Reach times cost, not reach alone, is the metric that should drive your hotfix order.

Setting it up with Bugnet

Bugnet captures crashes with full stack traces plus device and platform context, then groups identical crashes into one issue with an occurrence count and a distinct-players-affected figure. That grouping is what makes a players-affected ranking possible without manual tallying. Because each crash arrives with the game state and session context attached, you can see where in the session it fired and apply a severity weight instead of guessing. One dashboard shows every crash sorted by reach, so the bug hurting the most people is the one you open first.

The same data feeds your health gauge. Bugnet tracks how crashes spread across players and builds, so you can watch your crash-free picture improve after each hotfix and confirm that the crash you fixed was actually the dominant one. Filtering by platform or device attribute isolates the environment-specific crashes that gut feel would never surface. The product captures the crash, counts its reach, attaches the context that lets you weight its severity, and then shows you whether your fixes are moving the aggregate the right direction.

A repeatable triage loop

Turn all of this into a loop you can run in twenty minutes. Open the crash list sorted by players affected, glance at crash-free rate to gauge the overall fire, and pick the top one or two crashes whose reach and severity outweigh everything else. Fix those, ship the hotfix, then re-sort, because removing the biggest crash reshuffles the board and a new leader emerges. Repeat until crash-free rate climbs back into healthy territory and the top of the list is genuinely rare.

The discipline is resisting the urge to fix interesting crashes over impactful ones. There will always be a clever, satisfying bug that is fun to chase and barely affects anyone; let it wait. The crashes that decide whether players stay are usually mundane and high-reach, and the only reliable way to find them is to follow the data. A short, repeatable triage loop driven by occurrence counts and crash-free rate keeps you fixing what matters instead of what is fun.

Fix the crash hurting the most players, not the one that looked scariest. Rank by reach, weight by cost, and watch crash-free rate climb.