Set SLOs from real traffic and write the error budget policy

Define the service level objectives for this service and write the error budget policy that goes with them. Work from the numbers I give you. Where I have not given you a number, ask for it rather than choosing one for me.

What the service does, described as the thing a user is trying to finish: {{e.g. a checkout API that takes a cart and returns an order confirmation}}
Who depends on it: {{external customers, internal callers, other services, scheduled jobs}}
What a bad experience looks like from the user side: {{e.g. the confirmation takes more than four seconds; the order is accepted and then silently dropped}}
What I can measure today without new instrumentation: {{load balancer logs, application logs, traces, synthetic probes, client telemetry — say which of these exist}}
Behavior over the last four weeks: {{request volume, error counts by class, latency at p50/p90/p99, and any incident that already happened}}
Dependencies I do not control: {{third-party APIs, cloud services, and their published availability if you have it}}
Release cadence and who can halt it: {{e.g. we deploy on demand, roughly ten times a week; the platform lead can call a freeze}}

**Write each indicator in words before you write it as a metric.** State what it measures from the position of someone using the service. An indicator you cannot describe without pointing at a dashboard panel is measuring the system rather than the experience, and it will not survive its first argument with a product manager.

**Then express it as a ratio.** Good events divided by valid events, both sides defined precisely enough that I could implement it this week: which requests count, which are excluded, and where in the request path the measurement happens. Exclusions are where indicators quietly stop meaning anything, so justify every one of them. Name the measurement source you are assuming and say what that source cannot see, because a load balancer records a 200 for a page that rendered blank.

**Set the target from my data rather than from a round number.** Compute what the service actually delivered across the four weeks I gave you, then propose a target at or just below that, and show the arithmetic. Do not reach for 99.9% because it is conventional. If the service is currently delivering 99.3%, then 99.9% is a funded project rather than an objective, and you should say so in those words. Cap any target at what my dependencies can support and show that calculation separately.

**Convert the budget into units people will argue about.** For each objective, over a four-week window: the proportion of failures allowed, the same budget expressed as minutes of complete outage, and as a number of failed requests at my volume. Then estimate how much of it one incident of the kind I described above would consume. A budget nobody can picture does not change any decision.

**Write the policy as a document that can be approved.** It needs an owner, the people who approve it, the date it takes effect and the date it gets revisited. Then the part that matters: what changes when the budget is spent. Give the specific consequence at each threshold — half consumed, fully consumed, consumed with two weeks of the window remaining — and say who is accountable for carrying it out. Include the path for disagreeing with the consequence, because a policy with no escape hatch gets ignored rather than invoked.

**State what these objectives do not cover.** The failure modes that would leave every indicator green: correctness bugs, a dependency degrading in a way that returns 200, data that arrives complete and wrong. Name them so nobody reads a green dashboard as an all-clear.

**Close with what to instrument next.** If the best indicator for this service is not measurable from what I have today, say which one it is and what it would take to measure it, and give me the second-best indicator I can start with in the meantime.

Do not propose more than three objectives. A service with nine objectives has none, because nobody can tell you which one to protect when they conflict.

Tip: Bring the four weeks of numbers before you run this; without them the model will pick conventional targets and you will inherit a goal nobody measured against reality. Once the objectives exist, the burn-rate alerting that goes with them belongs in the alert triage prompt rather than here.