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 ericrisco/rsc-harness --skill monitoringgit clone --depth 1 https://github.com/ericrisco/rsc-harnessWrote 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/ericrisco/rsc-harness/monitoring)<a href="https://agentmods.dev/skills/ericrisco/rsc-harness/monitoring"><img src="https://agentmods.dev/badge/skills/ericrisco/rsc-harness/monitoring.svg" alt="Measured on agentmods" 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.00088 | $0.03058 |
| Opus 5 | $0.00044 | $0.01529 |
| Sonnet 5 | $0.00018 | $0.00612 |
| Haiku 4.5 | $0.00009 | $0.00306 |
Grade A, and why
monitoring scanned grade A with 1 finding 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 3d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
requests.get(PAYMENTS_URL) # blocks on a third party! How it starts
The opening of the file, as written. The whole thing — 156 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Monitoring
You are wiring up the outside view of a service that already shipped: is it alive, is it fast, and when it breaks, does exactly one human get exactly one actionable page. This skill emits a concrete setup — a checker config, a health-endpoint contract, symptom-based alert rules, and an on-call rotation. Not telemetry instrumentation (that is ../observability/SKILL.md), not the release-gating healthcheck (that is ../deployment/SKILL.md).
The one rule
A page is justified only when there is real user impact AND a human action the system can't take itself. Everything below descends from this. Internalize the three tiers:
- Page (wake someone): users are hurting now and a human must intervene. Checkout returns 5xx. Site unreachable. Error budget burning fast.
- Ticket (look during business hours): degraded but not bleeding. Slow-burn budget use, cert expiring in 14 days.
- Dashboard-only (don't notify): CPU at 80%, a single retry, a transient blip the system already healed.
If an alert doesn't map to an immediate human action, it is not a page — it's noise, and noise trains people to ignore the one page that matters.
The 4-layer stack
Don't skip layers and don't collapse them — each answers a different question.
| Layer | Answers | Built with | Fires when |
|---|---|---|---|
| 1. External uptime probe | "Is it reachable from the outside?" | Uptime Kuma / UptimeRobot / Better Stack | URL down, TLS broken, p95 latency over budget |
| 2. Health endpoints | "Is the process alive, and are its deps reachable?" | /livez + /readyz on the service |
liveness fails → restart; readiness fails → pull from rotation |
| 3. SLO burn-rate alert | "Are we spending the error budget too fast?" | Prometheus/Grafana/Better Stack rule | multi-window burn rate exceeds threshold |
| 4. On-call escalation | "Who acts, and who's the backup?" | PagerDuty / incident.io / Better Stack | a page from layers 1–3 routes + escalates |
Layer 1 catches "the whole thing is gone." Layer 2 catches "a dependency died" before users do. Layer 3 catches "we're degrading faster than we can afford." Layer 4 makes sure a human shows up.
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.
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.
- 3d ago First seen · 156 lines · 88 tokens per session scan A 2e27a75f7218
monitoring is a skill published in the GitHub repository ericrisco/rsc-harness (65 stars, last pushed yesterday), licensed MIT. It adds 88 tokens to every session and 3,058 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
alerting-config
Design effective alerting that catches real issues and minimizes false alarms.
build-subgraph
Traverses a full graph and returns a bounded subgraph around one target node -- its depth-bounded dependencies plus any disputed claims attached to it -- while proving everything else was left out.
merge-aliases
Folds two surface names for the same backend system into one canonical entity, keeping every original mention individually retrievable, and refuses to merge pairs that only share spelling.
anchor-and-lock
Consults a check that sits outside the loop system before finalizing any decision the frozen facts bear on, and refuses every attempt by a loop to rewrite a node marked frozen, regardless of how convergent the loop's own reasoning looks.
arbitrate-collision
Detects when two loops have proposed conflicting writes to the same node and field at close to the same time, applies a stated priority rule to accept exactly one, and records the rejected write with the reason it lost.
audit-sweep
Reviews a full set of the main loop's outputs together, from a wider vantage than any single one of them, looking specifically for cross-item patterns that a one-item-at-a-time loop is structurally unable to notice.