Write an SLO Definition Prompt That Ships Error Budgets Too

Most teams pick SLO numbers in a meeting, write them in a doc nobody reads, and never compute the error budget that's supposed to govern release decisions. The gap isn't knowledge. Google's SRE book already explains SLIs, SLOs, and error budgets clearly. The gap is repetition: you need the same rigorous output for every service, fast, without re-litigating the format each time. That's what an slo definition prompt gives you.

A prompt that's worth reusing doesn't just define terms. It takes a service description plus real latency and availability numbers, then returns candidate indicators, target objectives, and the error budget that falls out of them. Same structure every run. The reliability owner reviews a draft instead of staring at a blank page.

This post covers how to build that prompt, where models drift, and the output contract that keeps a fleet of services consistent.

What an SLO definition prompt actually produces

An SLO definition prompt is a reusable AI prompt that converts a service description and traffic profile into a structured reliability spec: the indicators worth measuring, the target for each, and the error budget those targets imply. The value is the locked output shape, not the prose around it.

Here's the distinction the ranking guides miss. The Google SRE book defines an SLO as a target for an SLI, with the classic example "99% of Get RPC calls complete in under 100 ms." Useful. But it stops at definitions. It doesn't hand you a formula for the budget, and it can't produce the same artifact for your forty microservices. Vendor guides like Nobl9's error-budget walkthrough do the math but wrap it in a platform pitch, with no copyable prompt to reuse.

You can do better with a {{service_description}} variable and an output contract.

What you can do with this prompt

• Draft SLIs and SLOs for a brand-new service before it ships, so reliability isn't an afterthought.
• Compute the error budget for an existing SLO and translate it into minutes of downtime or failed requests.
• Compare a proposed SLO against measured p50/p99 latency and flag targets that are already being missed.
• Generate the burn-rate alert thresholds that match the budget, so alerting ties to the SLO instead of raw metrics.
• Produce a consistent reliability spec across a whole service catalog, one run per service.

Anatomy of the prompt pack

The shape that holds up across models:

Variables
  {{service_description}}   – what the service does, who depends on it
  {{traffic_profile}}       – requests/min, peak vs trough, request types
  {{latency_baseline}}      – measured p50 / p95 / p99 in ms
  {{availability_baseline}} – current success rate over the last 28 days
  {{slo_window}}            – rolling window, e.g. 28 days

Prompt
  Role: reliability engineer defining SLOs from real signals.
  Task: propose SLIs, set SLO targets above measured baselines,
        compute the error budget, derive burn-rate alert thresholds.
  Output contract (locked):
    1. SLIs            – indicator, measurement, why it matters
    2. SLOs            – target, window, rationale tied to baseline
    3. Error budget    – budget = 1 - SLO, expressed in minutes AND failed requests
    4. Burn-rate alerts – fast-burn + slow-burn thresholds
    5. Open questions  – anything the human owner must confirm

The error budget line is the one most templates skip. The budget is 1 minus the SLO. A 99.9% target leaves 0.1%. Over a 28-day window that's roughly 40 minutes of downtime, or about 1,000 failures per million requests. State the window or the percentage is meaningless.

How models behave on this job

This is where naming the model matters. The behaviors aren't interchangeable.

Claude honors a ## Output contract heading more reliably than an inline "respond in this format" instruction, and it tends to keep the error-budget math attached to the right SLO across a long service description. GPT-4o is stronger at proposing sensible SLIs from a vague description but needs the output schema restated on the final line of the prompt, or it drifts into prose after the third section. Gemini will happily compute burn-rate thresholds but sometimes reports the budget as a percentage without converting to minutes unless you ask for both explicitly.

None of them know your real numbers. That's not a model limitation you can prompt away. Supply the baselines.

Prompt-craft patterns that lock the output

Pattern 1 — baseline-anchored targets. Don't ask for "a good SLO." Ask the model to set each target a defined margin above the measured baseline, and to flag any proposed target the service is already missing.

Set each SLO target above the measured baseline in {{latency_baseline}}.
If a proposed target is already being missed today, mark it
"AT RISK" and explain by how much.

Pattern 2 — budget in two units. Force the conversion. A budget stated only as "0.1%" gets ignored in planning; "40 minutes per 28 days" gets respected.

Express the error budget as BOTH a percentage and absolute terms:
minutes of allowed downtime over {{slo_window}} AND failed requests
per million, using {{traffic_profile}} to compute the request count.

Pattern 3 — the refusal boundary. Tell the model when not to guess.

If {{availability_baseline}} is missing or reads "unknown", do NOT
invent a target. List it under "Open questions" and proceed with the
indicators you can define.

That last pattern is the one that separates a draft a reliability owner trusts from one they quietly rewrite. Here's a take worth defending: an SLO the prompt guessed without a baseline is worse than no SLO, because it gives a false sense of governance. A blank "unknown" is honest. A fabricated "99.95%" is a trap that someone will later treat as real.

Variables you'll set

Leave a baseline blank and the prompt should route it to "Open questions" rather than guess. That's the behavior you want.

Getting started

1. Pull the last 28 days of latency percentiles and success rate for one service.
2. Write a two-line {{service_description}} and a one-line {{traffic_profile}}.
3. Paste both into the prompt with {{slo_window}} set to 28 days.
4. Run it on Claude first for contract fidelity, then sanity-check the budget math.
5. Have the reliability owner confirm anything in "Open questions" before the SLO goes in a doc.
6. Reuse the same prompt for the next service so the catalog stays consistent.

For the alerting half of this job, the burn-rate thresholds pair naturally with a tuning pass. See the companion post on an alert tuning prompt to reduce alert fatigue, which turns those thresholds into rules that don't page at 3 a.m. for nothing. And once an SLO is breached, the blameless incident postmortem prompt picks up where the error budget runs out.

The catalog has a few packs that touch this job directly: the Observability Instrumentation Harness for the telemetry SLIs depend on, and the Performance Regression Harness for the latency baselines you feed the SLO prompt.

Define the SLO once, compute the budget honestly, and reuse the prompt for the next service. That's the whole discipline. For the broader picture on choosing reusable prompts over one-off snippets, the post on how to choose a reusable AI prompt pack covers what separates a real pack from a copy-paste gist.