How do you define release criteria?

Direct answer

What a strong answer covers

How it works

Release criteria are the agreed conditions under which a build may go to users, decided before the release so they cannot be negotiated down under pressure. They combine functional evidence, such as the regression suite green and the new features verified, with risk evidence: no open defects above an agreed severity, security and dependency scans clean or with accepted exceptions, performance within thresholds on a production-like environment, and observability in place so problems will be seen. They include operational readiness: migration tested, rollback rehearsed, support briefed, and the stakeholder who owns the outcome signing off. Anything not met is either fixed or explicitly waived by that owner with the reason recorded.

Example

The release checklist for a payments update: regression suite green on the release candidate, all sev-1 and sev-2 defects closed, no critical dependency findings, checkout p95 under 400 ms in the staging load test, dashboards and alerts updated for the new endpoints, migration applied to a production snapshot in under 5 minutes, rollback tested, support team briefed, and sign-off from the payments product owner. One sev-2 was waived with a documented workaround and a fix date.

Common mistakes

• Deciding the criteria after the build is ready and adjusting them to fit.
• Counting tests passed as the criterion without regard to open risks.
• Releasing with no rollback rehearsal because the deploy has always worked.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.