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.
In this repository73 other files it gives its agents.
- AGENTS.mdAGENTS.md
- bigquery-analyticsSkill
- cache-invalidationSkill
- mongo-aggregationSkill
- mongo-modelingSkill
- postgres-aggregationSkill
- postgres-indexingSkill
- redis-coordinationSkill
- redis-patternsSkill
- review-querySkill
- code-migrationSkill
- cut-releaseSkill
- data-migrationSkill
- deploy-serviceSkill
- hotfixSkill
- rollbackSkill
- design-endpointSkill
- design-eventSkill
- design-schemaSkill
- evolve-contractSkill
- scaffold-nestjs-moduleSkill
- scaffold-projectSkill
- incident-responseSkill
- investigate-bugSkill
- on-callSkill
- postmortemSkill
- audit-skillsSkill
- distill-review-styleSkill
- write-skillSkill
- debug-with-tracesSkill
- instrument-serviceSkill
- evaluate-dependencySkill
- grillSkill
- handoffSkill
- orientSkill
- phased-deliverySkill
- spikeSkill
- to-questionnaireSkill
- write-adrSkill
- write-prdSkill
- devops-pr-reviewSkill
- go-backend-pr-reviewSkill
- nestjs-backend-pr-reviewSkill
- python-backend-pr-reviewSkill
- react-frontend-pr-reviewSkill
- bisectSkill
- break-couplingSkill
- dead-code-sweepSkill
- deslopifySkill
- extract-moduleSkill
- rebase-cleanSkill
- resolve-merge-conflictsSkill
- split-commitSkill
- tddSkill
- wait-whatSkill
- wide-renameSkill
- bullmqSkill
- kafkaSkill
- sqs-consumerSkill
- audit-dependenciesSkill
- The first 60 shown.
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
- Distinctive: line 43
Don't alert on: CPU/memory alone (unless it's about to cause user impact), single error events, things a retry handles.
- Distinctive: line 48
Every alert links a runbook: what it means, how to confirm, first mitigations, escalation.
- Distinctive: line 58
Check for alerts that never fire (dead) or always fire (ignored).
≈ “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.
Files
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).
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
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.

