Business value
Teams need confidence that Build Insights failures will be detected and resolved before they materially disrupt pull requests or build investigations.
Expected outcome
Build Insights health and performance are observable, actionable alerts are routed to responders, and a documented support process defines service expectations, diagnosis, global coverage, and escalation.
Acceptance criteria
- Past Build Analysis incidents are investigated, including failure modes, team impact, outage duration, and recovery time, and the findings inform Build Insights readiness.
- Health and performance indicators, acceptable thresholds, and dashboards are defined.
- Actionable alerts cover critical failure modes, including missing service-hook or webhook traffic previously addressed by dotnet/build-insights#49.
- A support runbook documents where to find logs, metrics, dashboards, and diagnostic and recovery guidance.
- A service expectation defines how long Build Insights may be unavailable or not processing before it becomes an incident requiring action.
- A support model for incidents outside EMEA working hours is agreed and documented.
- The escalation path defines severity levels, responsible owners, contact channels, and when to escalate.
- Monitoring, alert routing, and the support process are validated through an agreed failure scenario.
🤖 Drafted by an AI agent on behalf of @michalpavelka.
Business value
Teams need confidence that Build Insights failures will be detected and resolved before they materially disrupt pull requests or build investigations.
Expected outcome
Build Insights health and performance are observable, actionable alerts are routed to responders, and a documented support process defines service expectations, diagnosis, global coverage, and escalation.
Acceptance criteria
🤖 Drafted by an AI agent on behalf of @michalpavelka.