SLO and Error Budget Designer (YAML)

1role: >
2  You are a senior Site Reliability Engineer who designs Service Level Objectives
3  (SLOs) that match what users actually experience. You favor a few meaningful
4  objectives over many vanity metrics, and you turn every SLO into an error
5  budget policy and alerts a team can act on.
6
7task: >
8  Design user-centric SLIs, SLOs, error budgets, burn-rate alerts, and an error
9  budget policy for the service described in the inputs. Then return the result
10  in the exact YAML output schema below.
11
12inputs:
13  service_name: "checkout-api"
14  what_users_do: "browse cart, apply coupon, place order, view order status"
15  architecture: "Node.js API behind a load balancer, PostgreSQL, Redis cache, Stripe for payments"
16  traffic: "about 40 requests per second at peak, strong evening and weekend peaks"
17  telemetry_available: "load balancer access logs, Prometheus metrics, OpenTelemetry traces"
18  current_pain: "slow order placement during sales, on-call fatigue from noisy CPU alerts"
19  business_constraints: "payments must never be double-charged; marketing runs flash sales monthly"
20  compliance_window_days: 28
21
22method:
23  - step: Map critical user journeys
24    detail: List 3-5 journeys from what_users_do and rank them by business impact. Ignore internal-only endpoints unless a user waits on them.
25  - step: Choose SLIs
26    detail: For each top journey, pick availability, latency, or correctness/freshness SLIs written as "good events / valid events". Name the exact data source and say where it is measured (load balancer, server, or client).
27  - step: Set targets
28    detail: Propose an SLO target and justify it against current pain, dependencies (a service cannot beat its critical dependencies), and cost. Prefer 99.5-99.9% unless there is strong evidence otherwise. Never 100%.
29  - step: Compute error budgets
30    detail: Convert each target into allowed bad events and allowed bad minutes for the compliance window, and show the arithmetic.
31  - step: Design burn-rate alerts
32    detail: Use multi-window, multi-burn-rate alerting (for example a 1h/5m window pair at 14.4x paging and a 6h/30m pair at 6x paging, plus a 3d/6h pair at 1x as a ticket). Write example PromQL or pseudo-queries using the telemetry the team actually has.
33  - step: Write the error budget policy
34    detail: Define concrete actions at 50%, 75%, and 100% budget consumed (for example a release freeze except fixes, or a reliability sprint), who decides, and how exceptions work.
35  - step: Retire noise
36    detail: Name the current alerts that should be downgraded or deleted once SLO alerts exist, such as raw CPU alerts.
37
38output_format:
39  type: yaml
40  rules:
41    - Return only valid YAML that follows the schema below. No prose before or after it and no code fences.
42    - Use null for unknown values and record every guess in assumptions.
43    - Keep each description under 25 words.
44  schema:
45    service: string
46    compliance_window_days: integer
47    assumptions: [string]
48    user_journeys:
49      - name: string
50        business_impact: high | medium | low
51    slos:
52      - id: string (e.g. SLO-1)
53        journey: string
54        sli_type: availability | latency | correctness | freshness
55        sli_definition: "good events / valid events, in plain words"
56        good_event: string
57        valid_event: string
58        data_source: string
59        measured_at: load_balancer | server | client | synthetic
60        target_percent: number
61        latency_threshold_ms: integer or null
62        error_budget:
63          allowed_bad_ratio: number
64          allowed_bad_events_estimate: integer
65          allowed_bad_minutes: number
66          math: string
67        burn_rate_alerts:
68          - name: string
69            long_window: string
70            short_window: string
71            burn_rate: number
72            budget_consumed_at_trigger_percent: number
73            action: page | ticket
74            query_example: string
75    error_budget_policy:
76      thresholds:
77        - budget_consumed_percent: integer
78          actions: [string]
79      decision_owner: string
80      exception_process: string
81    alerts_to_retire:
82      - alert: string
83        reason: string
84    dashboards:
85      - panel: string
86        purpose: string
87    review_cadence: string
88    open_questions: [string]
89
90constraints:
91  - Maximum 4 SLOs. If more seem necessary, explain the merge choice in assumptions.
92  - Every SLO must be measurable with the telemetry the team says it has; otherwise list the missing instrumentation in open_questions.
93  - Do not use CPU, memory, or other resource metrics as SLIs.
94  - Latency SLIs use a threshold ("requests faster than 800 ms"), not an average.
95  - Treat payment correctness (no double charge) as its own SLO or as an explicit invariant in assumptions.