Why did my crash rate suddenly spike?

Almost always because a recent release introduced a new crash, the spike's timing usually points right at the build that caused it. A crash rate spike is a change from the baseline, and changes have causes: the most common is a new crash introduced by an update (new code that crashes under conditions you did not test), which surges the crash rate as players hit it. Other causes: an OS update that broke something (players' devices updating and the new OS version crashing your game), or a surge of players on a device/condition that triggers an existing crash. But the most common by far is a release-introduced crash. To find which, check your crash rate per version: if the spike started on a specific build, that release introduced the crash. Then identify the specific crash driving the spike (group by signature, rank by affected players, the new or surging signature on the spiking build). So your crash rate suddenly spiked most likely because a recent release introduced a new crash, which per-version data isolates (the spike starting on a specific build) and signature grouping identifies (the new crash driving it). Bugnet tracks crash rate per version and groups crashes by signature, so when your crash rate spikes you can see which build it started on (the cause) and which crash is driving it (the thing to fix), turning a sudden spike into a specific, actionable diagnosis, then roll back or hotfix and watch the crash rate recover per version.

How do I find the cause of a crash rate spike?

Isolate it to a version, then to a specific crash: check crash rate per version to find the build the spike started on, then rank crashes by affected players to find the crash driving it. Step one is per-version isolation: a spike that starts on a specific build means that release introduced the cause, so checking crash rate per version tells you which release to look at, narrowing a vague spike to a concrete change. If the spike does not align with a release (it started without a new build), suspect an external cause like an OS update, check whether the spiking crashes cluster on a specific OS version that recently rolled out. Step two is identifying the specific crash: group crashes by signature and rank by affected players, the crash driving the spike is the new or surging signature on the spiking version, and its captured stack trace, device, and OS tell you the cause (the code path, the conditions). So you find the cause of a crash rate spike by isolating it to a version (per-version data showing the build it started on, usually a release) and then to a specific crash (signature grouping and impact ranking showing the crash driving it, with captured context revealing why). Bugnet provides both, crash rate per version (to isolate the spike to a build) and signature grouping with impact ranking and full context (to identify the specific crash and its cause), so you can trace a spike from a vague alarm to the exact crash and the release that introduced it, then fix it and verify the crash rate recovers per version.

Should I roll back when my crash rate spikes?

Roll back if the spike is severe and the crash will take time to fix; hotfix if you can fix the driving crash fast. The choice depends on the spike's severity and your fix speed. If the spike is large (a serious crash hitting many players) and you cannot fix it quickly, roll back the release that introduced it, this immediately returns the crash rate toward the previous build's level, stopping the spike from affecting more players while you fix the cause without time pressure. If you can identify and fix the driving crash fast (the captured stack trace points clearly at the cause), hotfix, ship a targeted fix that resolves the crash, ending the spike without rolling back the rest of the release. To decide, you need the spike's severity (how many players the driving crash affects) and the context to gauge fix speed (the stack trace showing the cause), both from capturing crashes with context and ranking by impact. So roll back when the spike is severe and slow to fix, hotfix when you can fix the driving crash fast, and either way watch the crash rate recover per version to confirm the action worked. Bugnet's per-version tracking shows you the spike and which build caused it, its impact ranking shows the spike's severity (informing the call), and its captured context helps you gauge and execute a fast fix, then its per-version data confirms the crash rate recovered, so you can make and verify the roll-back-vs-hotfix decision with data.

What to Do When Your Crash Rate Spikes

Quick answer: Check per-version data to see if a release caused the spike, identify the crash driving it by ranking by affected players, and roll back or hotfix while watching the crash rate return to normal.

A crash rate spike means something changed, usually a new crash introduced by a recent build. The job is to isolate the cause fast and reverse it before it spreads. Here is what to do when your crash rate spikes.

Check Per-Version Data to Find What Changed

A spike has a cause, and it is almost always a recent change. Check your crash rate per version: if the spike started on a specific build, that release introduced the crash driving it. Per-version data isolates the spike to a version, telling you the release that caused it and turning a vague alarm into a specific lead.

Bugnet tracks crash rate per version, so when your crash rate spikes you can see which build it started on. That immediately narrows the cause to the change in that release, the difference between knowing a release caused the spike (and which) and staring at an aggregate number with no idea what changed.

Identify the Specific Crash Driving the Spike

A spike is usually one crash, not a general decline. Group crashes by signature and rank by affected players, and the crash driving the spike will stand out, the one that appeared or jumped on the spiking version. Identifying that specific crash gives you the exact thing to fix, rather than a vague stability problem.

Bugnet groups crashes by signature and ranks by affected players, so the crash driving the spike is identifiable, the new or surging signature on the spiking build. With the specific crash and its captured stack trace, device, and version, you know exactly what to fix, rather than guessing at a general crash rate increase.

Roll Back or Hotfix, Then Watch It Recover

Once you know the crash and the release that introduced it, reverse it: roll back the release if the spike is severe and a fix will take time, or hotfix the specific crash if you can fix it fast. Then watch the crash rate per version to confirm it returns to the pre-spike level on the new build.

Bugnet tracks crash rate per version, so after you roll back or hotfix you can watch the crash rate recover on the new build, confirming the spike is resolved. This closes the loop, you see the crash rate return to normal rather than hoping the fix worked, so you know the spike is genuinely over.

When your crash rate spikes, check per-version data for the build that caused it, identify the driving crash by impact, and roll back or hotfix while watching the rate recover. A spike almost always traces to a recent release.