#Finding flaky pipelines

You want the pipelines you already retried that failed anyway, and you want to see which of those failures came from a test and which came from a runner. A table that says only "failed" renders both the same way, and they have different owners and different fixes.

▍flaky-tests120×32

flaky-testsA recording of a flaky-pipeline list being built and then read. Pressing b and Enter selects the platform group, and Tab moves to the pipelines view. Pressing f opens the filter bar and status:failed with retried:true and updated under 7d is typed. Twelve rows remain, from six projects, each showing project, ref, queued time, duration and failure reason. Pressing P pins the tab as Failed again. The cursor then moves down the reason column: seven rows read script_failure, and five read runner_system_failure or stuck_or_timeout_failure with queued times between nine and fourteen minutes. One project, gateway, appears three times in the week, twice on main, all script_failure.

#Steps

Step	Key	What it does
1	b then Enter on platform, then Tab to pipelines	The group tree, CI view
2	f then status:failed retried:true updated < 7d	Retried, and failed anyway
3	P, named Failed again	Keeps the list as a tab
4	read the reason column	Splits the runner failures from the test failures

Read the tab column-wise rather than row-wise. A project that appears three times in a week, twice on main, all script_failure, has one broken suite that keeps being retried until it passes by luck.

#Reading the reason column

"Flaky" names two problems that look identical in a list.

A retried failure that fails again with script_failure is a test problem: either a genuinely non-deterministic test, or a broken one that occasionally passes. It belongs to whoever owns that suite.

A failure with runner_system_failure or stuck_or_timeout_failure was never a test. The runners died, or none was free. A retry hides it, which is how a capacity problem gets reported as flaky tests.

The queued column confirms the second case. Jobs that wait nine to fourteen minutes for a runner and then time out are a capacity problem with a specific fix, and nothing in the word "failed" says so.

#Row actions

Key	Action	Key	Action
Enter	the failing assertion, without opening a log	L	the full log, when the assertion is not enough
y	copy the failure block into an issue	/	narrow to one project to see the pattern

#Variations

#One project over time

When you already suspect a project, press b down to platform/gateway and filter to ref:main updated < 30d with no status filter at all. Every run of one branch for a month, passes and failures together, is where a test that fails one run in five becomes obvious. The preview also carries a sparkline of the last runs for that ref, so a pipeline that has crept from four minutes to eleven shows up here.

#Scheduled pipelines only

Add source:schedule to the Failed again filter and pin that as a second tab. Nightly builds fail differently from merge request pipelines, and usually nobody is watching them.