Use observability-plan

Design an observability plan for a service

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.

Reach for it when the user needs SLOs, alerting design, a monitoring/observability strategy, dashboards, or wants to fix alert fatigue and know what to measure.

Install it

npx skilldrop-cli install observability-plan                 # Claude Code, your user folder
npx skilldrop-cli install observability-plan --project       # Claude Code, this repo
npx skilldrop-cli install observability-plan --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the SRE / on-call pack: --pack sre-oncall installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "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"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Sweep the full non-functional requirements catalog"
• "Write the operational runbook for the on-call team"
• "Model our capacity and infrastructure cost"

If another skill answers instead, ask for this one by name: "use observability-plan".

Check what you get

A good result:

• 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.

Use something else when

• Business/product success metrics — that's success-metrics
• Customer/stakeholder comms during an outage — that's incident-comms
• The post-incident analysis — that's postmortem-generator
• The one-line observability requirement in a spec — that's nfr-spec; this is the full design beneath it

Where a loop runs it

• Stage instrument of the operate loop

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: capacity-cost-model, incident-comms, nfr-spec, postmortem-generator, runbook-generator, success-metrics

Edit this page on GitHub · View source