Error budget management
Purpose
Connect product delivery decisions to SLOs and error budgets with numeric burn, remaining budget, and explicit trade-offs—not generic "be more reliable" advice.
When to Use
- User asks about error budget, SLO burn, release freeze, or reliability vs features.
- Post-incident policy on shipping during elevated risk.
- Planning sprint focus when observability data shows fast burn.
When NOT to Use
- Raw dashboard queries → grafana, datadog, cloudwatch.
- Writing the postmortem → postmortem-authoring.
- Defining SLO implementations from scratch → monitor-slos.
Expected Outcome
- Short recommendation with SLO, burn rate, budget remaining, and suggested policy (freeze, slow down, or invest).
- Explicit tradeoffs for product and engineering leads.
Inputs to Gather
- SLO definitions and measurement window (30d rolling, etc.).
- Current burn rate and incidents in period.
- Upcoming releases and risk profile.
- Organizational policy on exhausted budgets.
Workflow
- Pull SLO/error budget signals from user or observability tools.
- State SLO target, current SLI, and budget consumed/remaining.
- Compare burn to policy thresholds.
- Recommend freeze, reduced risk releases, reliability sprint, or safe feature investment.
- Document assumptions if data is incomplete.
Domain guidance
Tie product pace to reliability objectives.
- State SLO and current burn; compare to budget remaining.
- If budget is exhausted or burning fast: recommend feature freeze, reduced risk releases, or reliability sprint.
- If budget is healthy: note where to safely re-invest (debt, features).
Output: short recommendation with numbers and explicit tradeoffs.
Tool Availability Rules
| Access |
Behavior |
| Full tool access |
Use metrics/SLO tools for live burn calculations. |
| Read-only |
Compute from user-supplied numbers; show formula. |
| No data |
Ask for SLO, SLI, and window; do not invent burn rates. |
Related tool sets
Review / Decision / Execution Criteria
- Numbers must be sourced or labeled as estimates.
- Recommendations proportional to burn severity.
- Align with blameless culture—policy, not blame.
Output Format
- SLO/SLI snapshot.
- Budget status (remaining %, burn rate).
- Recommendation (ship / slow / freeze / invest).
- Tradeoffs and assumptions.
Quality Bar
- Exec-readable in under one screen.
- Actionable policy guidance.
Safety and Boundaries
- Do not fabricate SLO metrics.
- Do not mandate production changes without stakeholder alignment.
Escalation / Dispatch Rules
- Metric proof → observability skills.
- Incident narrative → postmortem-authoring.
References
skills/old_skills.json (error-budget-management).skills/skill.instruction.md, skills/meta.instructions.md
1---2name: error-budget-management3description: Advises on SLOs, error budget burn, and release trade-offs such as feature freezes or reliability sprints. Use when balancing velocity against reliability targets.4---56# Error budget management78## Purpose910Connect product delivery decisions to SLOs and error budgets with numeric burn, remaining budget, and explicit trade-offs—not generic "be more reliable" advice.1112## When to Use1314- User asks about error budget, SLO burn, release freeze, or reliability vs features.15- Post-incident policy on shipping during elevated risk.16- Planning sprint focus when observability data shows fast burn.1718## When NOT to Use1920- Raw dashboard queries → **grafana**, **datadog**, **cloudwatch**.21- Writing the postmortem → **postmortem-authoring**.22- Defining SLO implementations from scratch → **monitor-slos**.2324## Expected Outcome2526- Short recommendation with SLO, burn rate, budget remaining, and suggested policy (freeze, slow down, or invest).27- Explicit tradeoffs for product and engineering leads.2829## Inputs to Gather3031- SLO definitions and measurement window (30d rolling, etc.).32- Current burn rate and incidents in period.33- Upcoming releases and risk profile.34- Organizational policy on exhausted budgets.3536## Workflow37381. Pull SLO/error budget signals from user or observability tools.392. State SLO target, current SLI, and budget consumed/remaining.403. Compare burn to policy thresholds.414. Recommend freeze, reduced risk releases, reliability sprint, or safe feature investment.425. Document assumptions if data is incomplete.4344## Domain guidance4546Tie product pace to **reliability objectives**.4748- State SLO and current burn; compare to budget remaining.49- If budget is exhausted or burning fast: recommend **feature freeze**, reduced risk releases, or reliability sprint.50- If budget is healthy: note where to safely re-invest (debt, features).5152Output: short recommendation with numbers and explicit tradeoffs.5354## Tool Availability Rules5556| Access | Behavior |57|--------|----------|58| Full tool access | Use metrics/SLO tools for live burn calculations. |59| Read-only | Compute from user-supplied numbers; show formula. |60| No data | Ask for SLO, SLI, and window; do not invent burn rates. |6162### Related tool sets6364- `jira`65- `github`6667## Review / Decision / Execution Criteria6869- Numbers must be sourced or labeled as estimates.70- Recommendations proportional to burn severity.71- Align with blameless culture—policy, not blame.7273## Output Format74751. SLO/SLI snapshot.762. Budget status (remaining %, burn rate).773. Recommendation (ship / slow / freeze / invest).784. Tradeoffs and assumptions.7980## Quality Bar8182- Exec-readable in under one screen.83- Actionable policy guidance.8485## Safety and Boundaries8687- Do not fabricate SLO metrics.88- Do not mandate production changes without stakeholder alignment.8990## Escalation / Dispatch Rules9192- Metric proof → observability skills.93- Incident narrative → **postmortem-authoring**.9495## References9697- `skills/old_skills.json` (`error-budget-management`).98- `skills/skill.instruction.md`, `skills/meta.instructions.md`
poly-gents