sla-definer-eng
Agent: Tech Architect
L2 technical architect (1x) responsible for feasibility assessment, system design, API contract definition, and infrastructure planning. Ensures technical decisions support product goals and scale requirements.
Department ethos: ideal-engineering.md
Skill Description
Defines the service-level agreements, objectives, and indicators that engineering teams target for uptime, latency, error rate, and throughput.
When to Use
- When a new service or system is being planned and needs explicit reliability and performance targets before development begins.
- When product or business stakeholders request formal availability guarantees for a customer-facing feature.
- When an existing service has no documented SLAs and incidents are being triaged without clear severity definitions.
Workflow
- Inventory services and dependencies: List all services in scope and their upstream/downstream dependencies. Identify which components are on the critical path. Deliverable: service dependency map with criticality annotations.
- Define SLIs: For each service, select the measurable indicators that reflect user-facing health (e.g., request latency p99, error rate, availability percentage). Deliverable: SLI catalog per service.
- Set SLO targets: Establish target values for each SLI based on business requirements, historical data, and infrastructure constraints. Distinguish between internal SLOs and external SLAs. Deliverable: SLO target table with justification.
- Define error budgets: Calculate the error budget for each SLO (e.g., 99.9% availability = 43.8 min/month of allowed downtime). Document how budget consumption triggers policy changes. Deliverable: error budget policy document.
- Establish measurement and alerting: Specify how each SLI is measured, where dashboards live, and what alert thresholds map to SLO burn rates. Deliverable: monitoring and alerting specification.
- Review and ratify: Present SLAs to engineering, product, and operations stakeholders. Incorporate feedback and get sign-off. Deliverable: ratified SLA document.
Anti-Patterns
- Aspirational SLAs: Setting targets based on wishes rather than measured baselines. Why: unrealistic SLAs erode trust when inevitably breached and train teams to ignore alerts.
- SLA without measurement: Defining targets without corresponding SLIs or dashboards. Why: an SLA you cannot measure is indistinguishable from having no SLA at all.
- Uniform targets across services: Applying identical SLAs to every service regardless of criticality. Why: non-critical services consume engineering effort maintaining unnecessary nines while critical services may be under-protected.
Output
On success: Produces an SLA document containing SLIs, SLO targets, error budgets, measurement methods, and alerting thresholds for each in-scope service. Delivered to the project repository and shared with engineering, product, and operations stakeholders.
On failure: Report which services could not have SLAs defined (e.g., missing baseline metrics, undefined business criticality), what data is needed, and recommended next steps to unblock.
Related Skills
1---2name: sla-definer-eng3description: This skill defines service-level agreements for engineering systems including uptime, latency, and error-rate targets. Use when asked to set SLAs, define reliability targets, or establish SLOs and SLIs. Also consider when launching a new service without defined availability expectations. Suggest when engineers are building without explicit reliability contracts.4---56# sla-definer-eng78## Agent: Tech Architect910L2 technical architect (1x) responsible for feasibility assessment, system design, API contract definition, and infrastructure planning. Ensures technical decisions support product goals and scale requirements.1112Department ethos: [ideal-engineering.md](../../../../departments/engineering/ideal-engineering.md)1314## Skill Description1516Defines the service-level agreements, objectives, and indicators that engineering teams target for uptime, latency, error rate, and throughput.1718## When to Use1920- When a new service or system is being planned and needs explicit reliability and performance targets before development begins.21- When product or business stakeholders request formal availability guarantees for a customer-facing feature.22- When an existing service has no documented SLAs and incidents are being triaged without clear severity definitions.2324## Workflow25261. **Inventory services and dependencies**: List all services in scope and their upstream/downstream dependencies. Identify which components are on the critical path. Deliverable: service dependency map with criticality annotations.272. **Define SLIs**: For each service, select the measurable indicators that reflect user-facing health (e.g., request latency p99, error rate, availability percentage). Deliverable: SLI catalog per service.283. **Set SLO targets**: Establish target values for each SLI based on business requirements, historical data, and infrastructure constraints. Distinguish between internal SLOs and external SLAs. Deliverable: SLO target table with justification.294. **Define error budgets**: Calculate the error budget for each SLO (e.g., 99.9% availability = 43.8 min/month of allowed downtime). Document how budget consumption triggers policy changes. Deliverable: error budget policy document.305. **Establish measurement and alerting**: Specify how each SLI is measured, where dashboards live, and what alert thresholds map to SLO burn rates. Deliverable: monitoring and alerting specification.316. **Review and ratify**: Present SLAs to engineering, product, and operations stakeholders. Incorporate feedback and get sign-off. Deliverable: ratified SLA document.3233## Anti-Patterns3435- **Aspirational SLAs**: Setting targets based on wishes rather than measured baselines. *Why*: unrealistic SLAs erode trust when inevitably breached and train teams to ignore alerts.36- **SLA without measurement**: Defining targets without corresponding SLIs or dashboards. *Why*: an SLA you cannot measure is indistinguishable from having no SLA at all.37- **Uniform targets across services**: Applying identical SLAs to every service regardless of criticality. *Why*: non-critical services consume engineering effort maintaining unnecessary nines while critical services may be under-protected.3839## Output4041**On success**: Produces an SLA document containing SLIs, SLO targets, error budgets, measurement methods, and alerting thresholds for each in-scope service. Delivered to the project repository and shared with engineering, product, and operations stakeholders.4243**On failure**: Report which services could not have SLAs defined (e.g., missing baseline metrics, undefined business criticality), what data is needed, and recommended next steps to unblock.4445## Related Skills4647- [`performance-budget-setter-eng`](../../../engineering/tech-architect/performance-budget-setter-eng/SKILL.md) -- performance budgets constrain the latency and throughput targets that SLAs codify.48- [`scale-infrastructure-planner`](../../../engineering/tech-architect/scale-infrastructure-planner/SKILL.md) -- infrastructure scaling plans must align with the availability and throughput targets defined in SLAs.
mittuled