Most advice on how to reduce flaky tests is tooling advice: install a detector, quarantine the worst offenders, add a retry wrapper. That work is real and it helps, but it treats flakiness as a property of individual tests. Teams that get their flake rate down and keep it down usually changed how they work first, and the tooling then had something to hold onto.
The mechanics of why a test flakes, the six root causes, and the healthy / flaky / broken rubric are covered in the guide to pipeline stability. What follows is the practice layer that sits above it: four changes to how a team works, in the order that makes each one stick, and where tooling belongs once they are in place.
1. Shorten the branch, not just the test
Long-lived feature branches manufacture flakiness. A branch that lives for two weeks accumulates merge conflicts with trunk, and the resolution of those conflicts produces exactly the conditions the root causes describe: shared state that behaves differently, ordering that changed, environment assumptions that drifted. The test did not become flaky on its own. The distance between the branch and trunk made it flaky.
Integrating at least daily removes that whole class. It also makes the remaining flakes far easier to attribute, because a change that broke something is one day of work rather than two weeks of it. This is the least popular item on the list because it is a change to how the team plans work rather than a change to the test suite, and it is the one with the largest effect.
2. Make the rerun policy explicit
Most teams have a rerun policy. Very few have written it down, which means in practice the policy is whatever the most impatient person on the team does. Rerun-as-reflex is the single habit that lets flakiness compound: every rerun that passes is a signal thrown away, and the test stays in the suite producing the same noise next week.
A written policy does not need to be elaborate. Something like: a rerun is allowed once, it must be recorded, and a second failure means the test is investigated rather than kicked again. The recording is the part that matters. A rerun that leaves no trace is invisible to every metric you might later use to decide what to fix, which is why teams that rerun freely are also the teams that cannot say which tests are worst.
The cost side of this habit, which is what usually persuades people to change it, is in the flaky test cost breakdown.
3. Give every flake an owner on the day it appears
Flaky tests survive because they belong to everybody. A test that fails intermittently annoys ten people slightly rather than one person enough to act, and slight annoyance never wins against a delivery deadline.
The fix is a named owner per newly detected flake, assigned the day it is detected rather than at a weekly triage meeting. Some teams run this as a rotating on-call for test health, which works well because it is bounded and visible. What matters is that the assignment happens while the change that surfaced the flake is still fresh in someone's memory. A flake investigated three weeks later costs several times what it costs on the day, because the context is gone.
Ownership also decides quarantine honestly. A quarantined test with an owner and a date is a managed risk. A quarantined test with neither is deleted coverage that nobody has admitted to deleting.
4. Hold the merge bar
Teams that allow merges on a red or partially green pipeline get more flakiness, and the causation runs in a direction people underestimate. Once merging on red is normal, a failing test stops being information. Nobody can tell whether a red run is the flake everyone knows about or a genuine regression, so genuine regressions land, and the suite loses whatever authority it had left.
Holding the bar is only fair once the first three are in place. Demanding a green pipeline from a team whose suite flakes constantly, with no rerun policy and no owner, is a way of making people miserable rather than a way of improving quality. Sequence matters: shorten branches, write the rerun policy, assign owners, then hold the bar.
Where tooling belongs once you reduce flaky tests by practice
With those in place, detection earns its keep, because now there is a process to hand a detected flake to. Detection tells you which tests flip and how often, which is the input to deciding what the owner works on first. Without an owner and a rerun policy, the same detection produces a list nobody actions, and the list itself becomes another thing the team feels bad about.
Pattern-matching a detected flake to one of the six root causes is where the time saving is. Each cause has a fix at a different boundary, and identifying the cause is usually quicker than guessing and rerunning. How detection reads test reports to get there is in the flaky-test docs, and the tactical fixes per cause are in how to fix flaky tests.
Retry wrappers deserve a specific warning. Automatic retries at the test-runner level suppress the symptom and destroy the signal at the same time, and they are worse than a manual rerun because a manual rerun at least involves a human noticing. If you use them, record every retry and treat the retry count as a first-class metric rather than an implementation detail.
Where CI/CD Watch fits
CI/CD Watch, a CI/CD observability platform that monitors pipelines across GitHub Actions, GitLab CI, Bitbucket Pipelines, CircleCI, Azure DevOps, and Jenkins, parses test reports to classify individual tests and whole pipelines as healthy, flaky, or broken, using flip rate, failure rate over the recent window, and age of last green.
That gives the practices above something objective to run on: a ranked list for the owner to work through, and a rerun count that makes the policy measurable rather than aspirational. The platform surfaces which tests are worst; deciding whether to fix, quarantine, or delete each one stays with the team that owns the code. Test-level stability detail sits on the paid tiers.
Start with the rerun policy
If only one thing changes this quarter, make it the rerun policy, because it is the cheapest to introduce and it is the precondition for measuring anything else. A team that records its reruns can tell you within a fortnight which tests are costing it most. A team that does not is guessing, however good its tooling is.
To put numbers against your own suite, connect a provider on the Free tier and let a few weeks of runs accumulate. Flip rate needs history to mean anything; a single week will not tell you which tests are genuinely flaky.
CI/CD Watch is built by 3CS Technologies Ltd, a UK consultancy that has run pipeline audits across regulated programmes and now runs the same engine inside the SaaS platform. We take the practices-first position on pipeline stability because detection without an owner produces a list, not a fix.