What should I do right after shipping a bad build?

Confirm it's bad via per-version comparison, then reverse it fast, roll back if broadly broken, hotfix if the issues are specific and fixable quickly, and verify the recovery. The moment you suspect a bad build, act with confirmation and reversal. First, confirm: compare the new build against the previous one in per-version data, if the new build's crash rate jumped or new crashes appeared, it's confirmed bad, and you see what it broke. Don't skip this, you want to know it's actually a regression (not coincidental) and exactly what's wrong before acting. Second, reverse it based on severity: if the build is broadly broken (high crash rate, many new issues), roll back to the last good build immediately, the fastest way to get players to a working state, fixing the build's issues afterward without the pressure of a live bad build. If the build broke one or two specific things you can fix fast (the captured context points clearly at the cause), hotfix those. Third, verify: confirm per version that stability returned (the rollback restoring the previous crash rate, or the hotfix dropping the new crashes), so you know the recovery worked. Speed matters, every hour a bad build is live is more players hitting its problems. So right after shipping a bad build, confirm it via per-version comparison, reverse it fast (roll back if broadly broken, hotfix if specific), and verify recovery. Bugnet's per-version tracking confirms the build is bad and shows what it broke, its context helps you hotfix or decide to roll back, and its per-version data verifies recovery, so you can respond to a bad build fast and with confidence rather than guessing.

Should I roll back or hotfix a bad build?

Roll back if the build is broadly broken or you can't fix it fast; hotfix if it broke a specific thing you can fix quickly, the choice depends on the build's damage and your fix speed. Both reverse a bad build, but they suit different situations. Roll back when: the build is broadly broken (a high crash rate, many new issues, fundamental breakage), or the issues are serious and you can't turn around a fix quickly, rolling back to the last known-good build is the fastest, safest way to restore players to a working state, and it buys you time to fix the build's problems properly without a live bad build hurting players. The downside is you lose the build's intended improvements until you re-ship a fixed version. Hotfix when: the build broke a specific, identifiable thing (one or two issues) that you can fix fast (the captured context points clearly at the cause), a targeted hotfix resolves the problems while keeping the build's improvements, avoiding a full rollback. The risk is that if you misjudge (the build has more problems than you fixed, or the hotfix introduces its own issues), you've spent time without fully recovering. To decide, you need to know the build's damage (how broadly it broke things, how severe) and gauge your fix speed (does the context show a clear, fast fix?). So roll back a bad build when it's broadly broken or slow to fix (restore the good state now), and hotfix when it broke something specific you can fix fast (resolve without losing the build). Either way, verify per version that stability returned. Bugnet's per-version data shows how broadly the build broke things (informing roll-back-vs-hotfix), its impact ranking and context show the severity and cause (gauging fix speed), and its per-version verification confirms whichever you chose worked, so you can make and execute the decision with data.

How do I avoid shipping bad builds?

Test before release, monitor per version after release, and gate releases on stability, so a bad build is caught before it ships or within minutes after, not after it's damaged players. You can't guarantee a perfect build every time, but you can catch bad builds before they cause much harm. First, test before release: test the changes (especially on real devices, where regressions hide on your dev machine), catching obvious breakage before it ships. Second, monitor per version after release: track crash rate and new crashes per build, so if a bad build does ship, you're alerted within minutes (the new build's crash rate spiking, new crashes appearing) rather than learning from players days later, letting you roll back or hotfix before the bad build spreads. Third, gate releases on stability: before a build goes wide, check it's not obviously worse than the previous one (per-version crash rate), and use staged rollouts where possible (releasing to a fraction of players first, so a bad build is caught on the small group before reaching everyone). Fourth, after each release, verify it's good (the new build's crash rate holding, no new high-impact crashes), so you confirm rather than assume. The combination, testing, per-version monitoring, gating, and staged rollouts, catches most bad builds early. So you avoid shipping bad builds (or limit their damage) by testing before release, monitoring per version after, gating on stability, and using staged rollouts, catching bad builds before or right after they ship. Bugnet's per-version crash tracking with spike alerts is central, it catches a bad build within minutes of shipping (the new build's crash rate climbing) and lets you gate by comparing a build's stability against the previous one, so bad builds are caught fast (limiting their reach) or before going wide (via staged-rollout monitoring), turning bad builds from a damaging surprise into a caught-and-reversed event.

What to Do When You Ship a Bad Build

Quick answer: Check per-version data to confirm the build is worse and see what it broke, then roll back to the last good build if broadly broken or hotfix specific issues, and verify per version that stability returns.

Shipping a bad build, one that's worse than what it replaced, happens to everyone. The key is confirming it fast, reversing it, and learning to catch it earlier next time. Here is what to do when you ship a bad build.

Confirm the Build Is Bad via Per-Version Data

First confirm the build is actually worse: compare it against the previous version. Check crash rate and new crashes per version, if the new build's crash rate jumped or new crashes appeared that weren't there before, the build is bad and you can see exactly what it broke.

Bugnet tracks crash rate and crashes per version, so you can confirm a bad build by comparing it against the previous one, the new build's crash rate up, new crashes present. That comparison both confirms the build is bad and shows what it broke, turning a suspicion into a clear picture of the regression.

Roll Back or Hotfix Based on Severity

Decide how to reverse it: if the build is broadly broken (many issues, high crash rate), roll back to the last good build, the fastest way to restore players to a working state. If it broke one or two specific things you can fix fast, hotfix those. Severity and fix speed determine which.

Bugnet's per-version data and full context inform the choice, showing how broadly the build broke things (roll back) or pinpointing specific issues (hotfix). Knowing the build's damage (how many issues, how severe) tells you whether rolling back or hotfixing is faster, and the captured context lets you execute either, then confirm it worked.

Verify Recovery and Tighten Your Process

After reversing, verify per version that stability returned, the rollback restoring the previous crash rate, or the hotfix dropping the new crashes. Then tighten your process: monitor per version after release and gate on stability, so the next bad build is caught before or right after shipping, not after damage.

Bugnet tracks per version, so you can confirm recovery (stability back to the good build's level) and set up per-version monitoring with alerts to catch the next bad build fast. This turns one bad build into a process improvement, you verify the recovery and add the per-version monitoring that catches future bad builds within minutes of shipping.

When you ship a bad build, confirm it's worse via per-version comparison, roll back if broadly broken or hotfix specific issues, and verify recovery per version. Then monitor per version and gate releases to catch the next one early.