You push a commit. The pipeline goes red. You run it again and get green.
No code changed. Nothing in the environment changed. And yet, the result is different.
If that sounds familiar, you're not alone. Flaky tests in test automation are one of the biggest hidden productivity drains in modern software delivery, and most teams are still treating them as a minor annoyance rather than a systemic problem.
Spoiler: they're not minor. And the way teams traditionally try to fix flaky tests? It mostly backfires.
Let's unpack why flakiness is a bigger deal than it looks, why flaky tests happen in CI/CD pipelines so persistently, and what a genuinely intelligent approach to flaky test detection actually looks like in 2026.
Flakiness isn't new, but it's scaling fast.
A benchmark analysis from Bitrise of over 10 million CI builds found that teams experiencing flaky tests jumped from 10% in 2022 to 26% in 2025, a 160% increase in just three years, as CI pipeline complexity grew by 23% over the same period, making detection harder.
Research published via the IEEE Software journal into Google's CI infrastructure adds a sharper edge: roughly 16% of all tests showed some level of flakiness, and the majority of red builds that teams investigate are false alarms, not regressions, just noise.
But here's what makes flakiness truly corrosive: it doesn't just waste time. It erodes trust. When developers can't tell whether a failing test means "something broke" or "the test is acting up again," they start ignoring results altogether. And the moment your test suite stops being trusted, it stops being useful.
Before getting into how to fix flaky tests, it would be helpful to understand the full cost, because most teams dramatically underestimate it.
According to engineering benchmarks across large-scale CI environments, 15-30% of total CI time is lost to flaky test reruns, and engineers spend 5-10 hours per week chasing false failures.
For a 50-engineer organization, that adds up to $180,000-$270,000 per year in lost developer time. Adding CI compute and deployment delay costs, total annual impact can push past $400,000.
A five-year industrial case study presented at the IEEE International Conference on Software Testing, ICST 2024, found that flaky tests consumed 2.5% of total productive developer time: 1.1% investigating false failures, and 1.3% repairing flaky tests.
That 2.5% sounds small. At enterprise scale, it's a structural tax on every single release.
Retrying a failing test is the instinctive response. But it doesn't fix anything, it just teaches teams to normalize failure. Every retry inflates CI duration. Over time, developers stop trusting red builds entirely. The safety net becomes background noise.
This is the question most teams skip straight past, and it's exactly why their fixes don't stick.
Understanding why flaky tests happen in CI/CD is the foundation of actually solving them. The most common root causes are:
Timing and synchronization issues: tests assume an element or response will be ready before it actually is
Asynchronous behavior: modern apps do multiple things at once, and tests often don't account for this gracefully
Unstable test data: data that works in isolation fails under parallel execution or after state changes from a previous test
Environment variability: flaky tests in CI/CD pipelines often behave differently from local runs due to resource constraints, network latency, or container startup timing
Shared state between tests: one test leaves behind state that breaks the next one
Third-party dependency instability: external APIs, services, or databases that aren't fully under your control
Locator drift: UI elements change between builds, breaking selectors that were valid yesterday
Among the mentioned causes, only the last one - locator drift - is what most self-healing tools actually fix. Everything else is still open. This is why flaky test detection needs to go deeper than locator management, and why the traditional toolkit consistently falls short.
Most tools have evolved to fight flakiness in some form: self-healing, smart retries, better locators, auto-remediation. These aren't useless, but they all share the same blind spot. They treat the symptom, not the cause.
Here's the honest breakdown:
| FIX | What It Solves |
What It Misses |
|---|---|---|
| Self-healing locators | UI element drift | Timing issues, async behavior, data instability |
| Retries | Gets you a green build | Defers real diagnostic work |
| Better locators | Narrow class of selector issues | Race conditions, environment variance |
| Auto-remediation | Script-level fragility | Systemic instability across environments |
The fundamental gap: traditional tools analyze test results one run at a time. But flakiness is a pattern that only surfaces across many runs, many environments, and many conditions simultaneously.
You can't spot a 3% nondeterministic failure rate by reading a single build log. You need cross-run reasoning, historical pattern analysis, and the ability to correlate failures with infrastructure signals. That's exactly where AI-powered flaky test detection starts to matter.
AI doesn't fix flaky tests by magic. What it does is detect patterns humans can't see at scale.
Modern AI-assisted QA systems analyze historical pass/fail probability per test, correlations between failures and environment load, timing sensitivity across parallel runs, and infrastructure and dependency signals together, giving teams a picture of suite behavior that no single build log could ever surface.
Industry practitioners flag any test exceeding a 2% nondeterministic failure rate as flaky, a threshold impossible to monitor manually at scale, but trivially trackable for a system processing execution histories continuously. You can explore how this connects to broader metrics that matter for agentic testing.
The shift isn't just in how to fix flaky tests individually. It's in moving from reactive firefighting to proactive detection, surfacing instability before it corrupts release signals and before teams lose faith in the pipeline entirely.
The most effective model emerging across mature QA organizations:
Autonomy with accountability. Speed without opacity. This is what responsible AI governance in QA looks like when applied to pipeline stability.
Launched in April 2026, Katalon True Platform was built around a specific premise: flaky tests in test automation are not a scripting problem. They're a systemic quality engineering problem.
Solving it requires AI agents, historical execution intelligence, and governance layered across the entire testing lifecycle. Here's how the platform approaches it:
At the core of True Platform's approach is the Probabilistic Flakiness Score (PFS), a stability metric that combines flip rate, retry rate, pass/fail unpredictability, and data confidence into a single score tracked over time.
Unlike a failure count, PFS reflects a test's long-term behavioral pattern. A test that passes 80% of the time gets flagged just as reliably as one that fails outright, because both are telling you something important.
The platform then classifies every test into one of four tags:
| TAG | What It Means |
|---|---|
| FLAKY | Long-term instability based on PFS, not just recent failures |
| ALWAYS FAILS | Consistently failing in the last 30 days |
| NEW FAILURE | Failed for the first time in the last 30 days (min. 10 runs) |
| SLOW | Execution time exceeds defined percentile vs. last 30 days |
This changes the conversation from "why did this test fail?" to "is this test behaviorally unstable, consistently broken, newly broken, or just slow?" - four different problems, four different solutions.
Test Run Details page while assessing test case failure. Flaky tests are flagged with tag [flaky]
Smart tags setup in Projection Configurations
One of the hardest parts of flaky test detection in CI/CD is distinguishing between three very different failure types: a real product defect, a broken test script, and an intermittently flaky test.
True Platform's Test Failure Pattern Analysis examines historical execution data to detect tests with intermediate failure rates (for example, failing 20-80% of the time), isolate environment-sensitive failures from script-level issues, and prioritize which tests pose the highest pipeline risk.
Each tag comes with an AI-powered Analyze option, not just a label, but a direct path to root cause explanation and suggested fixes. Instead of engineers spending hours in logs trying to understand why flaky tests happen in their specific CI/CD setup, the platform compresses that investigation into minutes.
When a UI changes: a button moves, an ID updates, a class name shifts, True Platform's AI agents detect the change and adapt the test automatically.
What makes this different from basic self-healing:
Every adaptation is logged and explainable
Changes are subject to human review before becoming permanent
The system handles timing and synchronization issues, not just locator drift.
Without context, a failing test is just a failing test. But that failure might be environmental, a flaky third-party dependency, an overloaded runner, a network blip.
True Platform unifies data across development, test execution, CI/CD pipelines, and production insights. This gives AI agents full situational awareness. When a test fails, the system has enough context to distinguish "the app regressed" from "the environment was unstable" from "this test has a documented history of flakiness under high load." Fewer false positives, more accurate flaky test detection, and less time wasted on the wrong diagnosis. This is the same principle behind agentic QA - AI that acts with awareness, not just speed.
In large teams, flakiness compounds over time because test maintenance can't keep pace with application change. Scripts drift. Data dependencies rot. Timing assumptions that held six months ago stop working.
True Platform's autonomous maintenance agents continuously generate and update test cases, repair outdated logic automatically, and reduce dependence on manual script updates. This tackles the structural causes of flaky tests in test automation, not just individual failures as they surface.
Some AI-augmented tools create a new kind of instability: the platform becomes a black box. Tests get modified, results change, nobody knows why. That's not how to fix flaky tests, that's just replacing one trust problem with another.
True Platform ensures every AI-driven action is auditable and explainable, engineers can override AI decisions at any point, and humans remain in control of release quality. For regulated industries or enterprises where accountability matters, this is non-negotiable. Read more about what AI governance in agentic testing requires in practice.
The metrics that matter in QA are shifting. Forward-looking teams are moving away from "flake count" and tracking deeper signals:
Pipeline trust metrics: do developers actually believe the results?
Stability trends per release: is the suite getting better or worse over time?
Review time saved: how much less time is spent on false failures?
Human override rate: how often are AI suggestions accepted vs. corrected?
The goal isn't zero flaky tests in test automation. In any sufficiently complex system, some nondeterminism is unavoidable. The goal is a CI/CD pipeline your team actually trusts, one where a red build means something, and a green build means something more.
Flaky tests don't announce themselves. They accumulate quietly, one ignored retry here, one normalized failure there, until the entire suite becomes more noise than signal.
Understanding why flaky tests happen in CI/CD is the first step. Knowing how to fix flaky tests with the right tooling is the second. But the real unlock is building a system with genuine flaky test detection at scale, one that monitors every test, every run, and every environment simultaneously and surfaces instability before it becomes a crisis.
Katalon True Platform represents one of the more mature approaches to this problem in 2026. The combination of PFS-based flaky test detection, intelligent failure tagging, self-healing execution, autonomous maintenance, and full governance transparency gives teams a practical path from "we have flaky tests" to "we understand our pipeline and trust what it tells us."
That trust, ultimately, is what a test suite is for.