393 Failures, 27 Root Causes - Triage by Spread, Not Volume
Rank by contexts blocked, not row count
Three hundred ninety-three red rows look like hundreds of distinct bugs. Leadership says fix everything. Teams treat symptoms. A week later the same capability path fails in another locale. The dashboard lied about volume; the leverage was in spread.
Here's what this piece covers: why volume prioritization fails, what the Jun 2026 L4 analysis showed (393 → 27), the manager-level algorithm, the named pattern, and three habits for cert weeks. Companion to tiered E2E L0–L4.
Part of Field Notes: agentic delivery.
1. The leadership problem
Red dashboards demand "fix everything." Engineers open the top ticket by raw count - often the tenth instance of a root cause that already blocks thirty contexts. Local fixes reopen across brand × region × browser while the systemic bug stays open.
Wrong: "393 failures."
Right: "~27 root causes - the same listing-filter failure counted thirty times; fix spread, clear the matrix."
The anti-pattern is volume prioritization - chasing row count while the high-spread root still blocks the release.
2. What the portfolio shows
Documented in docs/e2e-program-portfolio-summary.md and measured in docs/polaris-repeat-issues.md (generated 2026-06-22):
| Metric | Value |
|---|---|
| Total failing occurrences | 393 |
| Distinct issues (signatures) | 27 |
| Issues spanning >1 context | 25 |
| Widest single-issue spread | 30 contexts |
| Algorithm home | docs/repeat-issue-algorithm-spec.md (port of analyze_polaris_repeat_issues.py) |
One shared frontend codebase, many regional sites as configuration - same failure mode as article 06: fix one market, break another. Spread triage answers which fix clears the most red cells.
3. What I built: spread vs volume
| Lens | Measures | Mistakes it causes |
|---|---|---|
| Volume | Count of failing test rows | Staff the loudest stack of duplicates |
| Spread | Distinct brand / region / viewport / browser contexts per signature | Surfaces the handful of roots that unblock the most markets |
A systemic bug produces hundreds of rows. A local bug produces one. Ranking by distinct contexts is how triage meetings stop arguing about noise.
Top signatures in that L4 cut were capability-path failures - listing sort/filter controls, search landing on a product grid, mobile nav affordances - each repeating across brands, regions, and browsers. Fix the root once; up to thirty contexts go green.
def issue_key(failure):
# Do not key on raw "toBeVisible failed" alone - thousands share it.
return f"{failure.file} › {failure.title} :: {normalize(failure.error)}"
def context_hash(brand, region, viewport, browser):
return sha1(f"{brand}|{region}|{viewport}|{browser}")[:12]
def rank_by_spread(errors_map):
return sorted(
errors_map.items(),
key=lambda kv: len(set(kv[1])),
reverse=True,
)Manager-level loop: ingest Playwright brand-report JSON → group by signature → rank by distinct contexts → ship a leaderboard of highest-leverage fixes. Bug-grouping notes (e.g. Jun 24 buckets) pair the same idea for ticket intake - one SEO/hreflang root, many market clones.
4. Named pattern: spread triage
Spread triage - rank by contexts blocked, not row count - ~27 root causes, not 393 tickets.
| Outcome narrative | Confidence |
|---|---|
| 393 → 27 distinct issues | Verified in polaris-repeat-issues.md (2026-06-22) |
| ~90% noise reduction in triage meetings | Team-measured (portfolio narrative) |
| Part of broader ~35% defect-intake reduction | Team-measured - verify baseline before citing outside this series |
What broke: without root-cause IDs on tickets, the same path reopens as "new" work. Recurrence and chronic clusters get their own treatment in article 20.
5. What I'd do as a lead
Three habits - steal one this cert week:
- Never prioritize by raw failure count alone. Ask for spread before staffing.
- Staff one "spread captain" during cert weeks - owns the leaderboard, kills duplicate tickets.
- Close the loop: tag a root-cause ID in the tracker so recurrence is measurable, not folklore.
Further reading
- Previous context: Tiers beat the full matrix
- Upcoming: Chronic regression across thousands of tickets
- Planning:
docs/polaris-repeat-issues.md,docs/repeat-issue-algorithm-spec.md,docs/e2e-program-portfolio-summary.md
