A release blocker is an issue serious enough that we should not ship a release until it is resolved. The guiding principle is simple: a release should never make our software worse than it already is in production. Blockers are the cases where shipping would do exactly that.

New features that are majorly broken

If we are launching a new feature and it is majorly broken, that is a release blocker. Because the feature is new, the cleanest fix is usually to remove the risk entirely: revert the feature or disable it behind a flag, then let the release proceed without it. The feature can ship in a later release once it works.

Regressions of important functionality

If a release regresses functionality that already works in production, that is a release blocker. Here we do not ship around the problem — we hold the release until the regression is fixed, because shipping it would degrade behavior our users already rely on.

Bugs already in production

An important bug that already exists in production is not a release blocker. The release does not make the problem any worse, so there is no reason to hold it. If the bug is fixed shortly after, that fix simply goes out in a follow-up release. We block releases to prevent new harm, not to gate fixes for problems that are already live.