How do I roll back a bad update?

Revert to the last known-good build to immediately stop players hitting the problem, then diagnose and fix the issue properly before re-releasing a verified-stable build. Rolling back a bad update is about stopping the damage fast, then fixing right. First, revert to the last known-good build: deploy or re-publish the previous stable version (the one before the bad update), so new players get the working build instead of the broken one, this immediately stops the bleeding, removing the bad update from players' hands while you work on a fix. How you roll back depends on your platform (re-deploying a previous server build, re-publishing a previous app version, reverting a release), but the goal is the same, get players back on a working version fast. Second, confirm the rollback worked: verify (via per-version data) that the crash rate or problem returned to the previous build's good level, confirming the rollback stopped the issue. Third, diagnose and fix properly: with the bad build no longer live and the pressure off, use the captured data from the broken update (stack traces, conditions, per-version comparison showing what it broke) to find the root cause and fix it correctly, the rollback bought you time to do this right rather than rushing. Fourth, verify and re-release: before re-shipping the fixed build, confirm it's stable (test it, and on release monitor per version that it doesn't reintroduce the problem or cause a new one), so you don't repeat the bad release. So you roll back a bad update by reverting to the last known-good build (stopping the bleeding), confirming the rollback worked, fixing the issue properly using captured data, and verifying the fixed build before re-releasing. Bugnet's per-version data confirms which build was good (the rollback target) and that the rollback worked, preserves the captured crashes from the bad update (so you can fix it properly even after rolling back), and verifies the re-released fixed build is stable, so you can roll back, fix, and safely re-ship with the data to do each step right.

When should I roll back instead of fixing forward?

Roll back when the update is broadly broken, the issue is severe and widespread, or you can't fix it quickly, where reverting stops the damage fastest; fix forward when you can resolve the issue with a fast targeted hotfix. The choice between rolling back and fixing forward (hotfixing) depends on how broken the update is and how fast you can fix it. Roll back when: the update is broadly broken (many issues, a high crash rate, fundamental breakage, where individual fixes would take too long), the issue is severe and widespread (a game-breaking crash hitting many players, where every hour of damage is significant), or you can't fix it quickly (the cause is unclear or the fix is complex, so a fast forward-fix isn't feasible), in these cases, rolling back to the last good build stops the damage immediately, which is faster and safer than trying to fix a badly-broken live build, and buys you time to fix properly. Fix forward (hotfix) when: the issue is specific and you can fix it fast (a clear, contained cause that a targeted hotfix resolves quickly), so you can resolve it without losing the update's content/improvements, fixing forward is preferable when a fast, confident fix is available, since it avoids reverting the update's value. The deciding factors: breadth (broadly broken favors rolling back), severity and urgency (severe/widespread favors the fastest stop, often a roll back), and fix speed/confidence (a fast, sure fix favors fixing forward, an uncertain or slow fix favors rolling back to stop the bleeding while you work). When in doubt with a severe, widespread issue you can't immediately fix, rolling back is the safer choice, stop the damage first, fix properly second. So you roll back instead of fixing forward when the update is broadly broken, severe and widespread, or not quickly fixable, and fix forward when a fast targeted hotfix is available. Bugnet's per-version data shows how broadly the update broke things and how severe/widespread the issues are (informing breadth and severity), and its captured context helps you gauge fix speed (whether a fast forward-fix is feasible), so you can make the roll-back-versus-fix-forward decision based on data, then verify whichever path you took resolved the issue.

How do I fix the issue after rolling back?

Use the captured data from the bad update, the stack traces, conditions, and per-version comparison of what it broke, to diagnose the root cause and fix it properly, then verify the fixed build before re-releasing. Rolling back stops the damage but doesn't fix the underlying issue, so after rolling back you fix it properly using the evidence you captured from the bad update (the rollback doesn't erase that data). First, diagnose from the captured data: even though the bad update is no longer live, you have the crashes and context it produced, the stack traces (where it crashed), the conditions (device, OS, version), and the per-version comparison (what the update broke versus the previous build). Use these to find the root cause, the per-version comparison shows what the update changed for the worse, and the stack traces show where, together pointing at the responsible change. This diagnosis happens without time pressure (the bleeding is stopped), so you can do it thoroughly and find the real cause rather than a symptom. Second, fix the root cause properly: address the actual change that broke things (correct the code, revert just the problematic change while keeping the rest, fix the interaction), targeting the root so the re-release genuinely resolves it. Third, verify the fixed build: before re-releasing, test that the fix resolves the issue and doesn't break anything, and on re-release, monitor per version to confirm the fixed build is stable (the original issue gone, no new crashes), so you don't repeat the bad release. Fourth, re-release the verified build, restoring the update's intended content/improvements with the issue fixed. So you fix the issue after rolling back by diagnosing the root cause from the captured data (stack traces, conditions, per-version comparison), fixing it properly without time pressure, and verifying the fixed build before re-releasing. Bugnet preserves the captured crashes and context from the bad update and the per-version comparison of what it broke, so after rolling back you have the full evidence to diagnose and fix the root cause properly, then verify the re-released build is stable, ensuring the rollback leads to a genuinely fixed update rather than a repeat of the broken one.

What to Do When You Need to Roll Back an Update

Quick answer: Revert to the last known-good build to immediately stop players hitting the problem, communicate if needed, then diagnose and fix the issue properly using captured data before re-releasing, and verify the fixed release is stable.

Rolling back an update, reverting to the previous working build, is the fastest way to stop the bleeding when a release is broadly broken or can't be fixed quickly. Here is what to do when you need to roll back an update.

Revert to the Last Known-Good Build

The immediate goal is stopping players from hitting the problem, so revert to the last known-good build, the previous version that was stable. This instantly removes the broken update from new players' hands, stopping the bleeding while you work on a proper fix without a live bad build.

Bugnet's per-version data confirms which previous build was good (low crash rate) to roll back to, and confirms the rollback worked. Knowing the previous version's stability tells you it's a safe rollback target, and after reverting, the per-version data showing the crash rate return to that build's level confirms the rollback stopped the problem.

Diagnose and Fix the Issue Properly

With the bleeding stopped, diagnose and fix the issue properly: use the captured data from the broken update, the stack traces, conditions, and per-version comparison, to find the root cause and fix it right, without the time pressure of a live bad build. Rolling back bought you the time to do this correctly.

Bugnet captured the crashes and context from the broken update, so even after rolling back you have the evidence to diagnose and fix the issue properly. The captured stack traces and per-version comparison (what the update broke) let you find the root cause and fix it correctly, so your re-release resolves the issue rather than repeating it.

Verify the Fixed Release Before Re-Shipping

Before re-releasing, verify the fixed build is actually stable, ideally test it and, on release, monitor per version to confirm it doesn't reintroduce the problem or cause a new one. Rolling back and then re-shipping a still-broken build wastes the rollback, so confirm the fix held.

Bugnet tracks per version, so when you re-release the fixed build you can confirm it's stable, the original issue gone, no new crashes, rather than repeating the broken release. This verifies your fix worked before and after re-shipping, so the rollback leads to a genuinely fixed release, not another bad build that requires another rollback.

When you need to roll back an update, revert to the last known-good build to stop players hitting the problem, then diagnose and fix the issue properly using captured data, and verify the fixed build before re-releasing. Rolling back stops the bleeding and buys time to fix right.