# Create Service Levels > Define SLOs, SLIs, SLAs, and error budgets for a service so reliability targets are explicit and measurable. - **Type:** Skill - **Install:** `agentstack add skill-tomzx-agents-create-service-levels` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [tomzx](https://agentstack.voostack.com/s/tomzx) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [tomzx](https://github.com/tomzx) - **Source:** https://github.com/tomzx/agents/tree/main/skills/create-service-levels ## Install ```sh agentstack add skill-tomzx-agents-create-service-levels ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Create Service Levels Defines the service-level objectives, indicators, agreements, and error budgets that govern a service's reliability. Produces a single context-level artifact that `observe-production` checks against and `audit-observability` validates against. Without explicit SLOs, reliability is judged by gut feel: no one knows when a degradation is acceptable, when to freeze feature work, or what "healthy" even means. ## Prerequisites - Apply the shared SDLC conventions in `skills/sdlc/references/shared.md`. - `.sdlc/context/architecture.md` (must exist, to identify the services and their dependencies). - `.sdlc/context/goals.md` (optional, to align reliability targets with project objectives). - `.sdlc/context/service-levels.md` (optional; if present, revise rather than replace, per Revision Mode below). ## Steps 1. Read `.sdlc/context/architecture.md` to enumerate the services, endpoints, and critical user journeys. 2. Read `.sdlc/context/goals.md` if present, to align reliability targets with stated objectives. 3. For each critical user journey, define an SLI: what counts as a "good" event and a "total" event, and where that signal comes from. 4. Set an SLO target per SLI (start conservative; tighten as you measure). 5. Compute the error budget for each SLO (100% minus the target) and state the policy that applies when it is exhausted. 6. Define SLAs only where a contractual or external obligation exists; keep SLA targets looser than SLOs so internal headroom protects the agreement. 7. Specify burn-rate or threshold alerts that surface budget depletion before the window ends. 8. Confirm the measurement infrastructure can actually produce each SLI signal; flag gaps as open questions. 9. Write the output to `.sdlc/context/service-levels.md`. If it already exists, revise per Revision Mode. ## Output Format Use the template at `skills/sdlc/templates/context/service-levels.md`. Write the result to `.sdlc/context/service-levels.md`. ## Revision Mode If `.sdlc/context/review-service-levels.md` exists with `verdict: changes-requested`, revise the existing `.sdlc/context/service-levels.md` to address each finding rather than regenerating from scratch. Preserve content the review did not challenge. Set the artifact frontmatter `status` to `in-review` while revising, and bump `revision: ` starting at 1 on the first revision. ## SLO Design Guidance - **Start with the user, not the system.** Define SLIs over user-visible journeys (a request succeeded and returned fast enough), not internal counters that happen to be easy to measure. - **SLI = good / total.** A well-formed SLI is always a ratio. "Error rate" is `1 - (good / total)`. State both numerator and denominator explicitly. - **One window.** Use a single rolling window (commonly 30 days) across all SLOs so error budgets are comparable. - **Conservative targets first.** 99% is a fine starting SLO; you can tighten once you have measurement. An aspirational 99.99% you cannot meet is worse than a 99% you can. - **Error budget is the point.** The budget tells you when to freeze features and prioritize reliability. An SLO with no policy is decoration. - **SLA looser than SLO.** The SLO is what you hold yourself to; the SLA is what you owe a customer. Keep daylight between them. - **Few SLOs.** Three to five well-chosen SLOs beat twenty. Each one needs an owner and a policy. ## Outcome If `$OUTCOME_YAML` is set, emit `verdict: approved` there per `skills/sdlc/references/shared.md`. If the artifact could not be produced, omit the file. ## Example Usage **Scenario 1: HTTP API** Architecture describes a REST API serving a web app. User journey: a client makes a request and gets a valid response. SLI: `good = requests with status < 500 and latency < 800ms`, `total = all requests`. Source: the API gateway access logs. SLO: 99.9% of requests are good over a rolling 30-day window. Error budget: 0.1%, about 43 minutes per month. Policy: when budget drops below 25% remaining, freeze non-reliability feature work. SLA: 99.5% monthly uptime for the enterprise tier; breach triggers a service credit. **Scenario 2: Background data pipeline** Architecture describes a nightly batch job that exports records. User journey: the job completes and every queued record is processed. SLI: `good = jobs that finish before the deadline with zero dropped records`, `total = all job runs`. SLO: 95% of runs succeed fully over a rolling 30-day window. Alert: page if two consecutive runs fail. **Scenario 3: Library with no external users** Architecture describes an internal shared library. No user-facing service exists, so formal SLOs do not apply. Document this as out of scope and recommend measurement (test pass rate, release cadence) instead of availability SLOs. ## Completion Checklist Before handing off to review, confirm: - [ ] Each SLO has an error budget and a policy for when it is exhausted - [ ] SLAs (if any) are looser than their corresponding SLOs Self-check the draft against the [`review-service-levels` checklist](../review-service-levels/SKILL.md) and fix what you can, so review finds less to flag. ## Next Step Run `/review-service-levels` to audit the objectives for measurability, coverage, and policy soundness before relying on them. Once approved, `observe-production` and `audit-observability` consume `.sdlc/context/service-levels.md` directly. ## Useful Commands Reference No CLI commands required. This skill operates on document content provided in context. ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [tomzx](https://github.com/tomzx) - **Source:** [tomzx/agents](https://github.com/tomzx/agents) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-tomzx-agents-create-service-levels - Seller: https://agentstack.voostack.com/s/tomzx - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.