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.
npx skills add orlando-japan/claude-code-setting --skill alerting-hygienegit clone --depth 1 https://github.com/orlando-japan/claude-code-settingWrote 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.
[](https://agentmods.dev/skills/orlando-japan/claude-code-setting/alerting-hygiene)<a href="https://agentmods.dev/skills/orlando-japan/claude-code-setting/alerting-hygiene"><img src="https://agentmods.dev/badge/skills/orlando-japan/claude-code-setting/alerting-hygiene/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/orlando-japan/claude-code-setting/alerting-hygiene"><img src="https://agentmods.dev/badge/skills/orlando-japan/claude-code-setting/alerting-hygiene.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00034 | $0.01109 |
| Opus 5 | $0.00017 | $0.00554 |
| Sonnet 5 | $0.00007 | $0.00222 |
| Haiku 4.5 | $0.00003 | $0.00111 |
Grade A, and why
alerting-hygiene 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 9d 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.
How it starts
The opening of the file, as written. The whole thing — 103 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Alerting hygiene
A good alert:
- Fires on real user impact, not internal quirks.
- Is actionable — the oncall engineer can do something about it.
- Has a runbook.
- Fires rarely enough to stay trusted.
Fail any of those four and you're degrading the team's trust in the pager.
The test
For every alert, answer:
- User impact: what does the customer experience when this fires?
- Action: what does the oncall engineer do in the next 5 minutes?
- Runbook: where is the playbook?
- False positive rate: how often has this fired and been a no-op?
If any answer is "nothing" or "I don't know," the alert needs work.
What to alert on
Symptoms, not causes
- Good: "Error rate on /api/checkout exceeds 1% for 5 minutes."
- Bad: "Redis CPU at 80%."
Symptom alerts fire when customers are hurt. Cause alerts might be fine or might be a slow burn to a real problem; you can't tell from the alert alone.
SLO-based
If you have SLOs, burn rate alerts are the gold standard:
- Fast burn: you'll exceed the monthly budget in 1 hour at this rate → page.
- Slow burn: you'll exceed the monthly budget in 30 days at this rate → ticket.
Burn rate alerts handle both the acute incident and the slow drift without needing separate thresholds.
Availability and latency at the right quantile
- Alert on p95 or p99, not mean. Mean hides tail latency.
- Alert on absolute numbers, not relative ("more than yesterday"). Yesterday might have been broken too.
What not to alert on
- Resource metrics in isolation. "Disk 80% full" is a ticket; "disk is about to fill and cause outage in 10 minutes" is a page.
- Tests failing on a scheduled job. That's a CI issue, not a page.
- Individual errors. "One request failed" is noise. "Error rate crossed threshold" is signal.
- Things where the engineer can't act. "3rd party API is down" — if you can't fix it, why wake someone up? Inform the team via a different channel.
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.
- 9d ago First seen · 103 lines · 34 tokens per session scan A 5abc2cb439f0
alerting-hygiene is a skill published in the GitHub repository orlando-japan/claude-code-setting (2 stars, last pushed 3mo ago), licensed MIT. It adds 34 tokens to every session and 1,109 once invoked, about $0.0002 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-31.
Other skills, from other repositories
eng-runbook
A template for an engineering runbook, which is a practical guide engineers use during service operation and on-call incidents.
pager-triage
AI-powered incident triage for PagerDuty. List active incidents, deep-dive with timeline and alert correlation, check on-call schedules, acknowledge, resolve, and annotate — all from your agent. Read-only by default; write operations require explicit --confirm.
k8s-incident-triage
Read-only Kubernetes incident triage using kubectl. Accepts natural language or structured input. Produces root-cause hypotheses, evidence, and next-step commands.
monitoring
Use when setting up uptime and health monitoring, alerts, or on-call basics for a service already in production, so you learn it is down before customers do — health and readiness probes, alerting on SLO error-budget burn rather than raw counts, curing alert fatigue, on-call rotation with escalation, and a status…
sre_triage
SRE first-response triage for distributed training incidents. Automates the manual checks from PyTorch/NCCL debugging runbooks.
incident-runbooks
Operational skill for writing actionable oncall runbooks: symptoms, severity, diagnostics, mitigation steps, escalation, and post-incident links.