Categorize timeout failures for prioritized investigation

[premun]

Business value

Timeouts are one of the most common CI/CD failure modes in .NET, but today they surface as individual, unrelated failures — different error messages, tests, and platforms that often share a common underlying cause. With no way to group them, teams can't tell which timeout patterns hurt the most, and can't prioritize what to fix first. Grouping timeout failures into meaningful categories with aggregated statistics lets engineering teams prioritize timeout investigations by real impact.

Expected outcomes

• Timeout failures are grouped into meaningful categories that share a common pattern.
• Each category carries aggregated statistics — how often it occurs, its trend over time, and its blast radius (affected repositories/platforms).
• Teams can see, at a glance, which timeout categories to investigate first.
• Timeouts that don't fit an existing category are surfaced as candidates for review.

Acceptance criteria

• Timeout failures are detected and grouped into categories rather than shown only as isolated failures.
• For each category, teams can see aggregated stats (frequency, trend, affected repos/platforms).
• Categories are visible where teams already triage build failures.
• Uncategorized timeouts are identifiable as candidates for a new category or investigation.

Open decisions

• Historical scope — how far back to categorize existing timeout failures.
• Category lifecycle — whether categories are stable once created, or merge/split as patterns evolve.
• Actionability — whether high-frequency timeout categories should feed known-issue creation (see Related Maestro API with support for release pipelines #72).

Related (cross-cutting)

• Maestro API with support for release pipelines #72 Automated Known Issue Creation — recurring/high-impact timeout categories are natural candidates for auto-drafted known issues.
• Revert "Downgrade client to stable version" #61 / Trigger subscription command #77 / Update dependencies from dotnet/arcade #73 Known Issues stats & Data API — timeout-category statistics should also be available through the Data API, not just the UI.
• Update BAR so we can store additional AzDO build properties. #82 Public vs Outerloop builds — timeout statistics may need the same per-category breakdown.

Reference

De-solutionized rewrite of dotnet/arcade-services#6140 (original contains technical design notes for the implementing team).

---

🤖 Drafted by an AI agent on behalf of @michalpavelka.