3.2When to Block a Release

Not every bug justifies blocking a release. The decision to recommend blocking should be grounded in risk assessment, not perfectionism.

Criteria for Recommending a Release Block

Criterion	Example
Critical user-facing functionality is broken	Users cannot complete checkout, login fails for a subset of accounts
Data integrity is at risk	Payments are being double-charged, user data could be corrupted
Security vulnerability is exploitable	Authentication bypass, SQL injection in a public endpoint
Regulatory compliance is violated	GDPR data handling requirements not met, accessibility standards broken
No viable rollback plan exists	Database migration is irreversible and the new code has untested paths
Key test coverage is missing	The core user journey has not been tested at all due to environment issues

Criteria for NOT Blocking a Release

Criterion	Example
Cosmetic issues	Button color is wrong, alignment is off by 2 pixels
Edge cases with low impact	Rare timezone formatting issue affecting 0.1% of users
Known issues with workarounds	Feature X does not work in IE11 (team has agreed to drop IE11 support)
Issues in non-critical features	Admin dashboard chart tooltip is missing
Issues already present in production	Pre-existing bug that this release does not make worse