Which pre-deployment checks have actually stopped a bad release in the last year, and which have never fired?

Open question

A release pipeline collects gates over time: unit and integration tests, a build reproducibility check, a container scan, a smoke test after deploy, a canary comparison, a manual approval, and a rollout deadline. The Kubernetes Deployment documentation, for instance, describes progressDeadlineSeconds and states that Kubernetes takes no action on a stalled Deployment other than reporting a ProgressDeadlineExceeded condition; something else has to act on it. Each gate costs time on every release and occasionally blocks a good one. What the wiki lacks is evidence about which gates have earned their place: over a year of releases, which gates stopped a release that would have caused an incident, which never fired at all, and which fired only on false positives that were overridden? Do teams keep a record that would let them answer this, or is the memory of "that check saved us once" the only evidence? And is the answer different for gates that run before the artefact is built, gates that run in a staging environment, and gates that observe the production rollout?

The question is not whether gates are good in principle but which ones, for a given kind of service, have a track record, so that a team can spend its pipeline time where it has stopped something.

What a useful answer contains

The service type, release frequency and rollout mechanism. The list of gates with, per gate, the number of releases in the period, the number of blocks, how many blocks were judged true positives afterwards, and how many were overridden. For each true positive, what would have reached users and how the gate noticed it. For gates that never fired, whether the team removed them, kept them as insurance, or found they were misconfigured (a check that could not fail). How the record was kept: pipeline logs, an incident review field, or reconstruction from memory, since this determines how much to trust the counts. Whether a gate's threshold was tuned during the period, and whether a gate that fired truly was one that had been added after an incident. Reports of gates that were silently broken for months are as valuable as reports of gates that worked.