Design an observability plan for a service — user-journey SLIs, SLOs with error budgets, symptom-based burn-rate alerting (page vs ticket, every page actionable and runbook-linked), and a deliberate metrics/logs/traces split with a cardinality and cost budget. Use when the user needs SLOs, alerting design, a monitoring/observability strategy, dashboards, or wants to fix alert fatigue and know what to measure.
Pack sre-oncallTier standardJob Run and recover the servicev0.1.0
In Claude Code, with the sre-oncall plugin installed, invoke it as:
/sre-oncall:observability-plan
Try it
A realistic prompt from the skill's acceptance evals:
Design the observability plan for our checkout service — what should we measure, alert on, and page for?
What a good result looks like
SLIs measure user experience (good/valid events), not resource utilization. Latency SLIs are threshold counts at a percentile, never averages.
Every SLO has an error budget in human terms and a policy for when it's spent. A target with no budget consequence is decoration.
Pages are actionable, symptom-based, and runbook-linked. If a page doesn't require an immediate human action, it's a ticket — the plan re-tiers it.
Burn-rate alerting is used, not static "CPU > 80%" thresholds, for SLO-backed surfaces.
The three pillars are split by purpose, with high-cardinality identifiers kept off metrics. Logs are structured and budgeted.
A cardinality/cost budget exists. Observability without a cost ceiling becomes the surprise invoice.
Dashboards are defined by the question they answer, not by quantity.
How it's checked
Measured against plain Claude Code (2026-10-23): it met 62% of its checks, against 45% without it, and a blind judge preferred it. How skills are checked
18 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks
What the output must do
SLIs measure user experience as good-over-valid events, not resource utilization
Latency SLIs are threshold counts at a percentile, never averages
Every SLO carries an error budget stated in human terms plus a policy for when it is spent
Pages are symptom-based, actionable, and runbook-linked; anything not actionable is a ticket, not a page
The plan makes a deliberate metrics-vs-logs-vs-traces choice rather than proposing everything
Does not adopt the 99.999% target: explains that the dispensary system's 99.9% commitment, with no offline mode, caps what the refill journey can honestly promise, and sets a target with that in mind
Refuses patient ID and prescription ID as metric labels, giving both the cardinality cost and the health-data rule, and offers another way to trace individual complaints that keeps identifiers out of logs, labels and traces
Stops paging on causes that were rarely actioned (CPU, memory, pod restarts, any single 5xx) and makes pages depend on what patients experience
Handles the overnight low-traffic hours so that a handful of failed requests while branches are closed does not page anyone
Addresses the $1,500 cap against the current $2,100 and says what is cut or reduced to get there, with log ingestion as the main lever
Notes that the traffic figures conflict (40,000 a week in the overview, 40,000 a day in the constraints) and does not invent other traffic, alert or cost figures
Keeps the plan to about three pages
Recommends only one or a few alerts that would text her at night, each about customers being unable to reach the shop, check out or pay
Says most of the 25 items should not text her, and can go to email or an occasional check instead
Allows for the low order volume, for example by not alerting on 'no orders in the last hour' overnight or on one failed payment
Says what she or the web guy should do when each night-time alert fires
Does not invent details of her shop platform, tools or traffic beyond what she said
Delivers a few plain-language bullet points without stopping to ask questions first
When it should and shouldn't activate
Should activate:
Design an observability plan for this service
What SLIs and SLOs should we define, and what should page us?
Set up burn-rate alerting with error budgets
We alert on CPU and it's useless — design symptom-based alerting
Should leave to another skill:
Sweep the full non-functional requirements catalog
Write the operational runbook for the on-call team
Model our capacity and infrastructure cost
Write the postmortem for last week's outage
Hands off to
runbook-generator — when the alerts are defined and each needs a procedure. Write the procedure the on-call follows per alert.
incident-comms — when detection fired and an audience needs telling. Communicate at the stage the incident is actually in.