agentleFS
tejastn10tejastn10/workbench/skills/observability/define-alerts/SKILL.md

define-alerts

Skill1 starsChanged 2 months agoMITView on GitHub

Define alerts and SLOs that page on real user pain, not noise — pick SLIs from the RED metrics, set a target and error budget, alert on burn rate (multi-window), and make every alert actionable with a runbook link. Use when a service has no alerting, when asked to "add alerts / an SLO", or after an incident that nothing caught.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Don't alert on: CPU/memory alone (unless it's about to cause user impact), single error events, things a retry handles.

    line 43
  2. Distinctive:

    Every alert links a runbook: what it means, how to confirm, first mitigations, escalation.

    line 48
  3. Distinctive:

    Check for alerts that never fire (dead) or always fire (ignored).

    line 58

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Define alerts & SLOs

Rule: every alert that pages is a human waking up. If it's not worth that, it's a dashboard, not an alert.

SLIs — what to measure

From the RED metrics (observability/instrument-service), pick the few that represent the user experience:

  • Availability — 1 - (failed requests / total requests) for the endpoint(s) that matter.
  • Latency — proportion of requests faster than a threshold (p99 < 500ms → "99% of requests under 500ms").
  • For a consumer/pipeline — freshness (age of the newest processed item) and backlog (queue depth / lag).

Exclude what the user doesn't feel (health checks, internal cron).

SLO & error budget

  • Set a target: 99.9% over a rolling 28 days. That's ~40 min of budget/month.
  • The budget is the licence to move fast; burning it fast is the signal.

Alert on burn rate, not thresholds

  • Multi-window, multi-burn-rate: page when the budget is burning fast enough to exhaust in hours (e.g. 14.4× over 1h and 5m), ticket when it's a slow burn (3× over 6h). This catches real problems fast and ignores blips.
  • A raw error_rate > 1% alert fires on every transient spike — noise.

Also alert on (symptom, not cause)

  • Hard-down: no successful requests in N minutes.
  • Saturation with imminent impact: pool/queue/disk near capacity and climbing.
  • Certificate expiry, cron didn't run, deploy stuck.

Don't alert on: CPU/memory alone (unless it's about to cause user impact), single error events, things a retry handles.

Make it actionable

  • Every alert links a runbook: what it means, how to confirm, first mitigations, escalation.
  • Alert name says the user impact ("Checkout error budget burning fast"), not the metric ("http_5xx high").
  • Route by severity: page vs ticket vs Slack.

Verify

  • Trigger it in staging (or reason through a past incident) — would it have fired, and in time?
  • Check for alerts that never fire (dead) or always fire (ignored).

Anti-patterns

  • ❌ Threshold alerts on raw error rate / latency.
  • ❌ Paging on CPU or memory with no user impact.
  • ❌ An alert with no runbook.
  • ❌ Alert names that describe the metric, not the impact.
  • ❌ SLO target of 100% (no budget = no room to ship).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.