slo-definition

Defines service reliability targets by selecting SLIs, setting SLOs, and attaching error budget policies.

1|Updated Jul 3, 2026
One-click install
npx skills add https://github.com/Nandansai08/skillz --skill slo-definition-nandansai08
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: slo-definition
Source: https://github.com/Nandansai08/skillz/tree/main/skills/sre-incident-response/slo-definition
Command: npx skills add https://github.com/Nandansai08/skillz --skill slo-definition-nandansai08

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams set reliability targets from aspiration instead of measured baselines, or run error budgets that change nothing when exhausted. This Skill turns SLOs into targets with policies attached: measurable SLIs per user journey, numbers justified by data, and pre-agreed consequences when the budget burns. ## Core Features & Use Cases - SLI Selection per User Journey: Choose availability, latency, or freshness indicators measured at the user's side of the boundary, with a precise written spec of what counts as a good request. - Baseline-Driven Target Setting: Set SLO numbers from 4+ weeks of measured actuals, bounded by dependency ceilings and the cost of each additional nine. - Error Budget Policy: Derive the budget from the SLO and attach signed policies for healthy, fast-burning, and exhausted states before a crisis forces negotiation. - Use Case: A search service with chronic reliability arguments sets 99.9% availability and 97% latency SLOs on a 30-day rolling window; when a bad deploy burns 60% of budget, the pre-agreed freeze policy turns a release decision into a lookup instead of a fight. ## Quick Start Define SLOs for my search service using the last six weeks of latency and availability data, including an error budget policy.

Frequently Asked Questions about slo-definition

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I define SLOs for a service?▼

Pick 1-2 SLIs per critical user journey, write an exact spec of what counts as a good request, then set the target from at least 4 weeks of measured baseline data. Derive the error budget and attach a policy for what happens when it burns or runs out.

What is the difference between an SLI, SLO, and SLA?▼

An SLI is the measured indicator, such as the ratio of good requests to total requests. An SLO is the internal target on that indicator, and an SLA is the external contract with penalties. The SLO should be stricter than the SLA so alerts fire before the contract burns.

How do I choose which SLIs to measure?▼

Choose indicators per user journey, not per component: availability as good requests over total, latency as the fraction of requests under a threshold, and freshness for data pipelines. Measure at the load balancer or client side, since service self-reports score unanswered requests as perfect uptime.

Should I use rolling windows or calendar months for error budgets?▼

Use rolling 28 or 30-day windows. Calendar months create a budget refill day that invites gambling and makes identical incidents cost wildly different amounts depending on which side of a month boundary they fall.

When should I not use this SLO definition approach?▼

Do not use it to build the alerting layer itself; burn-rate alerts are a separate concern handled by alerting design. It also requires telemetry good enough to measure candidate SLIs for a few weeks, since targets set without baselines are aspirations.