Retry wins on expected value once your flake rate crosses about one in six

Start with the arithmetic a developer runs without writing it down. At Google's reported ratio, 84% of transitions from passing to failing involve a flaky test rather than a genuine regression ^[2]. The Microsoft figure for one investigation is 30 minutes ^[4]. So the expected value of investigating an unexplained red is 25.2 minutes of confirmed waste against 4.8 minutes of useful work ^[13]. Retry costs a minute of wall clock and no attention. Hitting it is the correct local decision, which is exactly the dev.to piece's argument: the developer's own experience says 85% of unexplained failures are environment, not code ^[9].

Slack's mobile suite is where the signal inverts outright. At a 56.76% failure rate ^[6], a red build is roughly 1.31 times more likely to be noise than a defect ^[15]. A check that is wrong more often than right is a coin toss with a CI bill attached.

The 150,000 hours a year Atlassian estimated before building detection tooling ^[5] is the number that will get quoted. Divide by Microsoft's half hour and you get 300,000 investigations a year, about 822 per calendar day ^[14]. Treat that as a claim about someone else's suite. For it to transfer you would need a comparable count of test executions reaching humans rather than auto-reruns, a similar ratio of flaky to genuine failures, and the same accounting of a developer hour, including the interrupt and not only the triage. The 30 minutes is Microsoft's number and the hours are Atlassian's, so the multiplication is illustrative, not measured.

What follows from this is a design problem, not a values problem. The mechanism I would build: rerun on the same commit to label a test deterministically, move labelled tests to a non-blocking lane, attach a named owner and an expiry date to the label, and let the blocking suite keep failing only on things worth stopping for. Quarantine does not fix flakes. It preserves the meaning of red while someone works through the four root causes the source lists, all of which it calls fixable: async timing, test-order dependency, shared mutable state, and coupling to external services ^[8]. They stay unfixed because they arrive in no sprint with an owner or a deadline, while user-facing features do ^[10].

Scope matters, and the source is honest about it. The rational-inaction framing is strongest at 20 or more engineers with separation between developer, QA, infrastructure and management, and it behaves differently under 10 where one person holds several of those seats ^[11]. If you are a team of six, this is ordinary prioritisation wearing a costume.

The threshold is the useful part of the argument. Once a team accepts that some failures are noise, the bar for investigating drifts upward, and the source puts mild skepticism as early as 5% flakiness ^[12]. Google's 16% is well past that ^[1], Microsoft's 25% of failures further still ^[3]. All four figures come from the same dev.to post, which does not carry primary links in the material supplied ^[18], so the individual percentages are worth verifying before you put them in a slide. The shape they describe is testable in your own CI in an afternoon. If you cannot state your suite's flake rate to one decimal place, the conversation about engineering culture is premature.