monitoring-observability
Skill16 starsChanged 5 days agoMITView on GitHub
Monitoring, metrics, alerting, and observability standards. TRIGGER when: implementing health checks, collecting metrics, or defining alert rules. SKIP: log statement formatting (use logging-standards); CI pipeline setup (use github-actions-template).
6 other projects use a version of this.
Adopted by
Most recently taken up by
- valentinesamuel/claude-skillstheir own version, first seen Nov 8, 2026
- DnsQueen/orcinus-skillstheir own version, first seen Nov 8, 2026
- mawero83/google-sre-skillstheir own version, first seen Nov 1, 2026
- eliabdevweb-svg/opencode-skills-MCPtheir own version, first seen Oct 9, 2026
- 2867203296/hermes-agenttheir own version, first seen Aug 19, 2026
- travisjneuman/.claudetheir own version, first seen Feb 25, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- travisjneuman/.claude★ 106same name
- mawero83/google-sre-skills★ 18same name
- DnsQueen/orcinus-skills★ 1same name
- valentinesamuel/claude-skills★ 1same name
- 2867203296/hermes-agent★ 0same name
- eliabdevweb-svg/opencode-skills-MCP★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository39 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- agent-commsSkill
- agent-memorySkill
- api-designSkill
- context-engineeringSkill
- database-optimizationSkill
- distillSkill
- docker-templatesSkill
- error-handlingSkill
- frontend-designSkill
- github-actions-templateSkill
- git-operationsSkill
- logging-standardsSkill
- mcp-toolsSkill
- mui-stylingSkill
- necessity-firstSkill
- pattern-recognitionSkill
- planning-methodologySkill
- python-patternsSkill
- quality-validationSkill
- react-patternsSkill
- research-methodologySkill
- reverse-engineer-anythingSkill
- security-review-checklistsSkill
- semantic-memory-mcpSkill
- skill-authoringSkill
- sofa-searchSkill
- spec-designSkill
- spec-developSkill
- spec-researchSkill
- spec-reviewSkill
- spec-workflowSkill
- state-managementSkill
- systematic-debuggingSkill
- testing-strategySkill
- ui-ux-pro-maxSkill
- verification-before-completionSkill
- watch-patternsSkill
- worktree-managementSkill
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
3
Distinctive
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 206
Use consistent time ranges
- Distinctive: line 217
Add annotations for deploys
- Distinctive: line 246
Create runbooks for alerts
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Monitoring & Observability Skill
Purpose
Standards for monitoring, metrics, alerting, and observability.
Auto-Invoke Triggers
- Setting up monitoring infrastructure
- Defining metrics and KPIs
- Configuring alerts
- Implementing distributed tracing
Three Pillars of Observability
| Pillar | Purpose | Tools |
| Logs | Event records | ELK, Loki, CloudWatch |
| Metrics | Numerical measurements | Prometheus, Datadog |
| Traces | Request flow | Jaeger, Zipkin, X-Ray |
Key Metrics (Golden Signals)
The Four Golden Signals
| Signal | Description | Example Metric |
| Latency | Response time | p50, p95, p99 latency |
| Traffic | Request volume | Requests per second |
| Errors | Failure rate | Error percentage |
| Saturation | Resource usage | CPU, memory utilization |
RED Method (Request-focused)
- Rate - Requests per second
- Errors - Failed requests per second
- Duration - Request latency
USE Method (Resource-focused)
- Utilization - Resource % used
- Saturation - Queue depth
- Errors - Error count
Application Metrics
HTTP Endpoints
| Metric | Type | Description |
http_requests_total | Counter | Total requests |
http_request_duration_seconds | Histogram | Request latency |
http_requests_in_flight | Gauge | Active requests |
http_response_size_bytes | Histogram | Response size |
Database
| Metric | Type | Description |
db_connections_active | Gauge | Active connections |
db_query_duration_seconds | Histogram | Query time |
db_errors_total | Counter | Query errors |
Business Metrics
| Metric | Type | Description |
users_registered_total | Counter | New registrations |
orders_created_total | Counter | Orders placed |
payment_amount_total | Counter | Revenue |
Metric Types
| Type | Use Case | Example |
| Counter | Cumulative totals | Requests, errors |
| Gauge | Current value | Temperature, queue size |
| Histogram | Value distribution | Latency buckets |
| Summary | Quantiles | p50, p95, p99 |
Naming Convention
{namespace}_{subsystem}_{name}_{unit}
http_server_request_duration_seconds
db_pool_connections_active
app_users_registered_totalAlerting Strategy
Alert Severity
| Severity | Response Time | Action |
| Critical | Immediate | Page on-call |
| Warning | Within hours | Create ticket |
| Info | Next business day | Review |
Alert Rules
- Alert on symptoms, not causes
- Include runbook links
- Set appropriate thresholds
- Avoid alert fatigue
- Group related alerts
What to Alert On
| Alert | Condition | Severity |
| Service down | Health check fails | Critical |
| High error rate | > 5% errors | Critical |
| High latency | p99 > 2s | Warning |
| High CPU | > 80% for 5min | Warning |
| Disk space | < 20% free | Warning |
| SSL expiry | < 30 days | Warning |
SLOs and SLIs
Service Level Indicators (SLIs)
- Availability: Successful requests / Total requests
- Latency: % requests < threshold
- Throughput: Requests per second
- Error rate: Failed requests / Total requests
Service Level Objectives (SLOs)
| SLO | Target | Error Budget |
| Availability | 99.9% | 43.8 min/month |
| Latency (p99) | < 500ms | - |
| Error rate | < 0.1% | - |
Error Budget
- Monthly allowed downtime
- Spend on risky deployments
- Freeze deploys when exhausted
Distributed Tracing
Concepts
| Term | Description |
| Trace | End-to-end request journey |
| Span | Single operation in trace |
| Context | Trace ID propagated across services |
What to Trace
- Cross-service calls
- Database queries
- External API calls
- Message queue operations
Trace Propagation
- Pass trace context in headers
- Standard: W3C Trace Context
- Headers:
traceparent,tracestate
Health Checks
Endpoint Types
| Endpoint | Purpose | Response |
/health | Basic liveness | 200 OK |
/health/ready | Full readiness | 200 + deps status |
/health/live | Process alive | 200 OK |
Readiness Check Components
- Database connection
- Cache connection
- External service connectivity
- Required configuration present
Health Response Format
{
"status": "healthy",
"checks": {
"database": "healthy",
"cache": "healthy",
"external-api": "degraded"
},
"version": "1.2.3"
}Dashboard Design
Layout Principles
- Most important metrics at top
- Group related metrics
- Use consistent time ranges
- Include context (deploy markers)
Standard Panels
- Overview - Traffic, errors, latency
- Resources - CPU, memory, disk
- Dependencies - DB, cache, external APIs
- Business - Domain-specific metrics
Best Practices
- Link to runbooks
- Add annotations for deploys
- Use consistent colors
- Set reasonable refresh rates
Runbooks
Structure
- Alert description - What triggered
- Impact - User/business effect
- Diagnosis steps - How to investigate
- Resolution steps - How to fix
- Escalation - Who to contact
Required Runbooks
- Service restart procedure
- Database failover
- Rollback deployment
- Scale up/down
- Incident communication
Best Practices
DO
- Monitor the four golden signals
- Set up alerts before incidents
- Create runbooks for alerts
- Use distributed tracing
- Track SLOs and error budgets
- Review dashboards regularly
DON'T
- Alert on every metric
- Ignore alert fatigue
- Skip health checks
- Forget to trace async operations
- Set unrealistic SLOs
- Neglect runbook maintenance
Observability Checklist
Metrics
- Golden signals tracked
- Custom business metrics
- Resource utilization metrics
- Dependency health metrics
Alerting
- Critical alerts defined
- Severity levels set
- Runbooks linked
- On-call rotation configured
Tracing
- Trace context propagated
- Key operations traced
- Trace sampling configured
Dashboards
- Service overview dashboard
- Dependency dashboard
- Business metrics dashboard
- Deploy annotations enabled
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.

