observability

observability is a skill for Claude Code from proyecto26/system-design-skills. It costs 148 tokens per session (3,034 once invoked), scanned A, original, MIT.

A design guide for observability: seeing whether a running system works through measurements, logs, traces, health checks, and alerts.

In plain words
What is it for?
Use it to choose production measurements, define health checks and service targets, design dashboards, trace requests across services, and decide which alerts need human action.
Why use it?
It helps teams notice failures quickly and understand what happened, instead of learning about outages from users.

Skill for Claude Code

Written for Claude Code: shipped in a Claude Code plugin.

Part of the system-design-skills plugin — 22 skills, 1 command, 1 agent shipped together

Good fit Use it to choose production measurements, define health checks and service targets, design dashboards, trace requests across services, and decide which alerts need human action.

Compare 6 skills from other repositories ↓
Install with agentmods
npx agentmods add skills/proyecto26/system-design-skills/observability
Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Any agent
npx skills add proyecto26/system-design-skills --skill observability
Clone the repo
git clone --depth 1 https://github.com/proyecto26/system-design-skills

Made for: Claude Code.

Or install system-design-skills, the plugin that ships this one along with the rest of its 22 skills, 1 command, 1 agent.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for observability

README.md
[![agentmods](https://agentmods.dev/badge/skills/proyecto26/system-design-skills/observability.svg)](https://agentmods.dev/skills/proyecto26/system-design-skills/observability)
Your own site
<a href="https://agentmods.dev/skills/proyecto26/system-design-skills/observability"><img src="https://agentmods.dev/badge/skills/proyecto26/system-design-skills/observability.svg" alt="Measured on agentmods" height="20"></a>
Per session 148 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 3,034 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5.1 $0.00148 $0.03034
Opus 5 $0.00074 $0.01517
Sonnet 5 $0.00030 $0.00607
Haiku 4.5 $0.00015 $0.00303

Measured 8d ago against content hash 43b91b6f2f89, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-07, from the pricing page.

Security

Grade A, and why

observability scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/observability/SKILL.md · 194 lines

How it starts

The opening of the file, as written. The whole thing — 194 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Observability

Decide what to measure so a system can be seen, alerted on, and debugged in production. Getting this wrong is failure mode #6 — ignoring failure: a design that works on the whiteboard but goes dark under load, where the first signal of an outage is a user complaint instead of a page.

When to reach for this

Any production design needs an answer to "how would we know this broke, and how fast?" Reach for this when defining what the system measures, what pages a human, what an acceptable level of service is (SLO), or how a request is traced across services. It is the design move that makes every other block's stress section real — you cannot mitigate a thundering herd or a hot shard you can't see.

When NOT to

Do not build a full metrics-logs-traces stack for a prototype or an internal tool with no users to disappoint (YAGNI) — a health check and error logging are enough. Do not invent SLOs nobody will defend, or wire alerts before knowing the symptom that matters; an alert with no owner and no runbook is noise that trains the team to ignore pages. This skill owns what to measure and alert on; the high-volume log pipeline (collect → buffer → ship → index → retain) lives in distributed-logging — summarize and link, don't rebuild it here.

Clarify first

  • What is "healthy" from a user's view? The symptom that defines a bad experience (slow checkout, failed upload) — alerts target this, not CPU.
  • SLO target and window? e.g. 99.9% of requests < 300 ms over 30 days. This sets the error budget and the alert thresholds. (→ back-of-the-envelope for the nines.)
  • Request volume and cardinality? QPS drives metric/trace sample rates; high-cardinality labels (user ID, URL) blow up a metrics store.
  • Is this request-driven or resource-driven? Picks RED (services) vs USE (CPU/disk/queues) as the measurement frame.
  • Multi-service request path? If a request crosses services, tracing earns its keep; a single service may not need it yet.

Read the full file on GitHub · 194 lines

Files

What ships with it

5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 8d ago First seen · 194 lines · 148 tokens per session scan A 43b91b6f2f89

Subscribe to this mod's changes

observability is a skill published in the GitHub repository proyecto26/system-design-skills (69 stars, last pushed 3mo ago), licensed MIT. It adds 148 tokens to every session and 3,034 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

chief-financial-officer

Owns the financial position: planning, budgeting, forecasting, unit economics, cash, and the numbers the business is run and reported on. Use this to build or challenge a budget, model a decision's financial consequence, assess unit economics or runway, evaluate an investment or spend request, set financial controls…

cbrock84/headcount · 88 tokens

service-desk

Runs the IT service desk — intake, triage, prioritization, escalation, knowledge, and the metrics that improve service rather than distort it. Use this to set up or fix a service desk, design ticket priority and escalation, reduce repeat contacts, structure a knowledge base, or work out why a desk hitting its targets…

cbrock84/headcount · 73 tokens

chief-revenue-officer

Owns the revenue engine end to end: sales, monetization, pricing, customer success, retention, and partnerships. Use this for pricing and packaging decisions, sales strategy and coverage, forecast and pipeline health, churn and expansion, partner and channel strategy, or when marketing-sourced demand is not…

cbrock84/headcount · 80 tokens

chief-strategy-officer

Owns where the business plays and how it wins over a multi-year horizon — portfolio choices, corporate development, strategic partnerships, and planning under uncertainty. Use this for a decision about which markets or businesses to be in, whether to build, buy, or partner, how to allocate capital across business…

cbrock84/headcount · 93 tokens

support-operations

Designs and runs the support function — channels, queues, routing, staffing, service levels, quality, and the metrics that show whether it is working. Use this to set up or fix support operations, choose channels, size a team, set or renegotiate service levels, reduce cost per contact, diagnose long queues or poor…

cbrock84/headcount · 77 tokens

voice-of-customer

Builds the loop from what customers say to what gets changed — collecting feedback, distinguishing signal from noise, routing it to owners, and closing the loop back to the customer. Use this to set up a feedback program, design or interpret CSAT/NPS, decide what customer feedback deserves action, get product to act…

cbrock84/headcount · 82 tokens