Reading failure clusters across three release windows

When a nightly suite paints hundreds of red rows, the instinct is to open tickets one by one. That approach hides the pattern: many failures share a fixture, a browser profile, or a data seed that shifted between releases.

Start by exporting results for the last three release candidates. Keep the same columns—suite name, case id, environment, duration, and first-fail timestamp. Sort by environment first, then by fixture name if your runner records it.

A cluster is useful when at least five cases fail together on the same tag and recover together after a single change. Document that cluster as one signal in your readiness notes instead of five separate defects. Release managers then see a countable set of blockers rather than a wall of red.

Discard clusters that appear only on a single agent or laptop. Those usually reflect local pollution, not product risk. Keep clusters that survive a clean agent image; those belong in the go/hold conversation.