Do I need a known-good build for my game?

Yes, you should keep a known-good build, a specific version you have verified is stable that you can fall back to, because releases sometimes turn out to be broken, and having a verified-stable version to roll back to lets you limit the damage while you fix the problem properly. Without a known-good build, a bad release leaves you with only one option: scramble a forward fix under pressure, which is risky and slow, during which players keep hitting the broken release. With one, you can roll back immediately to restore players to a working experience, then fix forward calmly. The key is that a known-good build is only useful if you actually know it is good, which means having verified its stability with real data (crash rate, impact) rather than just assuming, and knowing which build that was. That requires tracking stability per version. Bugnet provides this: it tracks crashes and stability per version, so you know which builds were genuinely stable (met your bar, low crash rate) and can confidently identify your known-good build to roll back to, and it alerts you when a release breaks (your signal to roll back) and confirms when your fix works, which is why you need a known-good build and how to know which build qualifies.

How do I know which version of my game to roll back to?

Know which version to roll back to by tracking the stability of each version, so you can identify the most recent version that was verified stable (met your stability bar, had a low crash rate, no critical issues), that is your known-good build to roll back to. The risk in rolling back is rolling back to a version that was also problematic (just differently), so you need actual stability data per version, not assumptions, to pick a genuinely good fallback. With per-version stability tracking, each release has a record: crash rate, impact, critical issues, so when a new release breaks, you can look back and find the last version that was confirmed stable and roll back to it with confidence. You also want to confirm the broken release is actually the problem (that the issue is new in it), which per-version crash data shows. Bugnet provides this: it tracks crashes and stability per version, so you can see which versions were stable and which introduced problems, letting you identify the right known-good version to roll back to and confirm the bad release is the cause, which is how you know which version of your game to roll back to.

What's a rollback strategy for a live game?

A rollback strategy for a live game is a plan to quickly revert to a known-good build when a release turns out broken, stopping the damage immediately while you fix the problem properly, rather than only being able to fix forward under pressure. The components: keep known-good builds (verified-stable versions you can fall back to), monitor releases closely (so you detect a broken release fast, the trigger for rollback), have a fast path to roll back (the technical ability to revert players to the previous good build quickly), and pair rollback with fix-forward (roll back to stop the bleeding, then fix the issue calmly and re-release). The strategy depends on two things working: knowing immediately that a release is broken, and knowing which previous build is genuinely good to roll back to, both of which require per-version stability data. Bugnet provides both: real-time crash alerts per version tell you immediately when a release is broken (triggering rollback), and per-version stability tracking tells you which prior build was known-good (the safe rollback target) and confirms when your forward fix works, so your rollback strategy is driven by data rather than guesswork, which is what a rollback strategy for a live game looks like.

Do You Need a Known-Good Build?

Quick answer: Yes, keep a known-good build, a verified-stable version to fall back to, so if a release breaks you can roll back and limit damage while you fix; this requires tracking stability per version.

A known-good build is your fallback when a release goes wrong. Here is whether you need one.

Why You Need One: A Fallback for Bad Releases

You need a known-good build because releases sometimes turn out broken, and having a verified-stable version to fall back to lets you roll back, restoring players to a working experience, while you fix the problem properly. Without a known-good build, a bad release leaves you with only the choice to scramble a forward fix under pressure.

Bugnet helps you identify your known-good build: by tracking crashes and stability per version, it shows you which versions were actually stable, so you know which build to keep as your fallback, the one the data confirms was good, not just the one you assume was.

How You Know a Build Is Good

A known-good build is only useful if you actually know it is good, which means having verified its stability with real data, not just assuming. Knowing a build is good requires tracking its stability (crash rate, impact) so you can confirm it met your bar, and knowing which build that was when you need to fall back.

Bugnet provides that knowledge: it tracks stability per version, so each build has a stability record, letting you identify with confidence which version was genuinely known-good (met your stability target, low crash rate) and is safe to roll back to, rather than guessing which past build was actually stable.

Rollback Plus Fix-Forward

A known-good build supports a rollback-plus-fix-forward strategy: when a release breaks, roll back to the known-good build to stop the bleeding immediately, then fix the problem properly and re-release. The known-good build buys you time to fix correctly rather than forcing a rushed, risky forward fix under pressure.

Bugnet supports both halves: it tells you immediately when a release is broken (real-time crash alerts per version, your signal to roll back) and confirms when your forward fix works (the crash stops in the new version), so the rollback-and-fix-forward cycle is driven by data, with the known-good build as your safe fallback.

Yes, keep a known-good build, a verified-stable version to fall back to, so a broken release can be rolled back to limit damage while you fix forward; knowing which build is good requires per-version stability tracking.