How do I know if my game has a bad build?

Look for problems coinciding with the build's release, especially via per-version data. The direct sign is a crash spike or new failures right after the build ships (the new build crashing or failing in ways the previous one didn't). A telling sign is the game broken in obvious ways (won't start, core loop broken, your change obviously not working, blunt breakage a quick check would have caught). And a sign is complaints starting right when the build shipped (a wave of reports coinciding with the release). To detect a bad build, track crashes per version with alerts: this catches the new build crashing more or new failures appearing right after release, in minutes, so you catch the bad build fast. If a crash spike or new failures coincide with the build, the game is broken in obvious ways, or complaints started with the release, you have a bad build. A bad build usually ships because it wasn't verified as the actual build, you tested the editor or an older build, not the thing you shipped, so a problem specific to the actual build (or a last-minute change) went out unchecked, which is why the breakage is often obvious (a quick smoke test of the real build would have caught it). So you know your game has a bad build from the problems coinciding with its release (a crash spike, new failures, obvious breakage, complaints starting with the build), and per-version tracking with alerts is how you catch it fast (the new build performing worse, visible in minutes). Once you know the build is bad, you stop the bleeding fast (roll back to the previous good build if you can, or hotfix), since a bad build hitting players is doing damage. Catching bad builds fast (per-version monitoring) and preventing them (smoke-testing the actual build before shipping, gating on a regression check) is how you avoid the self-inflicted wound of shipping a build broken in obvious ways.

Why do bad builds get shipped?

Most often because the actual build that shipped was never tested, the team verified the editor, a debug build, or an earlier version, but not the final release artifact, so a problem specific to that build (or a last-minute change) went out unchecked. This is why bad builds are often broken in obvious ways: a quick smoke test of the actual build (does it launch, does the core loop work, does your change work) would have caught the blunt breakage, but if nobody ran the real build, it shipped broken. Other causes include skipping verification under deadline pressure or on momentum ('it's a small change, just ship it'), not having a regression check (so breakage in untouched features slips by), and not gating release on any verification (so nothing stops a broken build from going out). The common thread is a gap between what was tested and what was shipped, the build that went out wasn't verified, so its problems weren't caught. So bad builds get shipped because the actual release build wasn't tested (the editor or an old build was, not the real artifact), often compounded by skipping verification under pressure, not checking for regressions, and not gating release. The fix closes that gap: smoke-test the actual release build before shipping (so you've run what you ship, catching the obvious breakage), run a regression pass and gate release on it (so an unverified or broken build can't go out), and monitor per version after release (so anything that still slips through is caught fast). Bad builds are largely self-inflicted and preventable with these checks, the obvious breakage that defines a bad build is exactly what a quick smoke test of the real build would catch, so the prevention is simply to verify the actual build before shipping (and gate on it), rather than assuming the build is fine because the editor or an old build was. Catching bad builds that do slip through (via per-version monitoring with alerts) limits their damage, but preventing them (smoke-testing the real build, gating) is what stops the self-inflicted wound of shipping a build broken in obvious ways.

What should I do if I shipped a bad build?

Stop the bleeding fast, usually by rolling back to the previous good build, then fix and re-ship properly, since a bad build hitting players is doing damage every minute it's live. Once you've identified the bad build (via per-version monitoring showing the new build crashing more or new failures, or the obvious breakage and complaints), the priority is to limit how many players the bad build affects, so the fastest mitigation is often to roll back to the previous known-good build, which immediately ends the problem by reverting players to a build you know works (while a hotfix takes time to write, test, and ship, during which players keep hitting the bad build). So if you can roll back, do that first to stop the bleeding, then diagnose what made the build bad (per-version crash data shows the new failures, and since a bad build often wasn't verified, smoke-test to find the obvious breakage), fix it, and re-ship a verified build (this time smoke-testing the actual build before shipping, so you don't ship another bad one). If rollback isn't possible, ship a fast hotfix instead, but the principle holds: mitigate first (stop the bad build from hitting more players), fix properly second. Communicate with players if the bad build was widely hit (acknowledge it, note the fix), since how you handle it affects trust. And learn from it: a bad build usually ships because the actual build wasn't verified, so add a smoke test of the real build before shipping (and gate on it) to prevent the next one. After re-shipping, verify the new build is good (per-version tracking shows the problems resolved). So the response to a bad build is: catch it fast (per-version monitoring), stop the bleeding fast (roll back to the previous good build if you can, since the bad build is doing damage), fix the cause and re-ship a verified build (smoke-tested this time), communicate, and add the smoke-test/gate to prevent recurrence. The key is speed (a bad build live is doing damage, so mitigate fast, usually rollback) and prevention (the bad build shipped because the actual build wasn't verified, so smoke-test the real build before shipping going forward). Having per-version monitoring (to catch bad builds fast) and a rollback path ready (to stop the bleeding) is what lets you respond quickly when a bad build does ship, and smoke-testing the actual build before shipping is what prevents the bad build in the first place.

Signs Your Game Has a Bad Build

Quick answer: Watch for a crash spike or new failures on the new build, the game broken in obvious ways, a regression, and complaints starting when the build shipped. A bad build usually ships because it wasn't verified as the actual build.

A bad build, one broken in a way you'd have caught with a quick check, is a self-inflicted wound. Here are the signs your game has a bad build.

A Crash Spike or New Failures on the New Build

The direct sign is a crash spike or new failures right after the build ships, the new build crashing or failing in ways the previous one didn't. If the build's release coincides with a crash spike or new failures (visible per version), the build is bad, it introduced problems.

Bugnet tracks crashes per version and alerts on spikes, so a bad build's problems are caught fast. A crash spike or new failures on the new build are the direct sign of a bad build, and per-version tracking with alerts catches them fast (the new build crashing more, new signatures), so you catch the bad build in minutes rather than days from reviews.

The Game Broken in Obvious Ways

A telling sign is the game broken in obvious ways, won't start, core loop broken, your change obviously not working, blunt breakage a quick check would have caught. If the build is broken in obvious ways (not just subtle edge cases), it's a bad build that wasn't smoke-tested before shipping.

Bugnet captures crashes with version context, so build-breaking problems are identifiable. The game broken in obvious ways is a sign of a bad build (one that shipped without being smoke-tested), the blunt breakage (won't start, core loop broken) is exactly what a quick smoke test of the actual build would have caught, so its presence signals the build wasn't verified before shipping.

Complaints Starting Right When the Build Shipped

A sign is complaints starting right when the build shipped, a wave of reports coinciding with the release. If players started complaining (crashes, broken features) right when the new build went out, the build is bad, the timing (problems starting with the release) attributes them to the build.

Bugnet tracks crashes per version, so problems coinciding with a build are identifiable. Complaints starting right when the build shipped are a sign of a bad build, and per-version tracking confirms the timing (problems appearing on the new build), which attributes the complaints to the build, so you know the build is bad and can roll back or fix it.

Watch for a crash spike or new failures on the new build, the game broken in obvious ways, a regression, and complaints starting when the build shipped. A bad build usually ships because it wasn't verified as the actual build.