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.
