Test Quarantine
Moving an intermittently failing test out of the blocking suite into a tracked, owned backlog, so a red build keeps meaning something.
A flaky test does more damage than a missing one. It trains the team to rerun the pipeline rather than read the failure, and once that reflex exists it is applied to real failures too. The purpose of quarantine is to protect the signal.
The mechanism: detect flakiness automatically — the same commit passing and failing is a sufficient definition — move the test out of the blocking suite, raise a ticket with an owner and a deadline, and continue running it in a non-blocking job so its behaviour stays visible.
Two rules keep quarantine from becoming a graveyard. It must be bounded: a cap on how many tests may be quarantined at once, and a deadline after which a quarantined test is either fixed or deleted. And the underlying cause must be investigated rather than assumed, because a meaningful proportion of flaky tests are detecting real non-determinism in the system — a race, a time dependency, an ordering assumption — and deleting them removes the only evidence of a genuine defect.