error-observability
Skill0 starsChanged 3 months agoMITView on GitHub
Implement structured error handling, logging, metrics, and observability. Covers error hierarchies, correlation IDs, log levels, alerting thresholds, and health check endpoints.
In this repository44 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- a11y-auditSkill
- ai-engineerSkill
- api-clientSkill
- changelog-enforcerSkill
- code-cleanup-guardianSkill
- code-reviewerSkill
- contract-testSkill
- db-migrateSkill
- dep-auditSkill
- devops-automatorSkill
- env-configSkill
- frontend-designSkill
- git-commit-helperSkill
- github-issues-managerSkill
- git-issue-syncSkill
- git-protocolSkill
- handoffSkill
- incident-responseSkill
- init-projectSkill
- karpathy-guidelinesSkill
- market-researcherSkill
- parallel-agent-git-isolationSkill
- product-strategistSkill
- pr-workflowSkill
- rapid-builderSkill
- release-managerSkill
- resumeSkill
- scrutinizeSkill
- shadcn-uiSkill
- skill-builderSkill
- sprint-plannerSkill
- state-machine-diagramsSkill
- state-managementSkill
- surveySkill
- system-architectSkill
- tech-docsSkill
- unstuckSkill
- ux-design-systemSkill
- ux-researchSkill
- webapp-testingSkill
- web-dev-fundamentalsSkill
- workflow-optimizerSkill
The file
Files
Error Handling & Observability
Error Hierarchy Design
Base Error Structure
class AppError extends Error {
constructor(
message: string,
public readonly code: string, // Machine-readable: "AUTH_TOKEN_EXPIRED"
public readonly statusCode: number, // HTTP status: 401
public readonly isOperational: boolean, // true = expected, false = programmer error
public readonly context?: Record<string, unknown>
) {
super(message);
this.name = this.constructor.name;
}
}Error Categories
| Category | Retry? | Alert? | Log Level | Example |
| Validation | No | No | warn | Invalid email format |
| Authentication | No | On spike | warn | Expired token |
| Authorization | No | On spike | warn | Insufficient permissions |
| Not Found | No | No | info | Resource doesn't exist |
| Conflict | No | No | warn | Duplicate entry |
| Rate Limit | Yes (backoff) | On threshold | warn | Too many requests |
| Upstream Failure | Yes (circuit breaker) | Yes | error | Third-party API down |
| Internal | No | Yes | error | Null pointer, type error |
| Infrastructure | Yes (limited) | Yes (page) | fatal | Database unreachable |
Decision Tree: Retry vs. Fail
Is the error transient?
├── Yes → Has retry budget remaining?
│ ├── Yes → Retry with exponential backoff (base * 2^attempt + jitter)
│ └── No → Fail with "service temporarily unavailable"
└── No → Is it a client error (4xx)?
├── Yes → Return error to client with helpful message
└── No → Log, alert, return generic 500Structured Logging
Log Format (JSON)
{
"timestamp": "ISO-8601 timestamp",
"level": "error",
"message": "Payment processing failed",
"correlationId": "req-abc123",
"service": "payment-service",
"traceId": "trace-xyz789",
"error": { "code": "PAYMENT_DECLINED", "message": "Card declined by issuer" }
}Log Level Guidelines
| Level | When | Example |
| debug | Development-only detail | Variable values, query parameters |
| info | Normal operations worth recording | Request completed, user logged in, job finished |
| warn | Unexpected but handled | Retry succeeded, deprecated API used, rate limit approaching |
| error | Failure requiring investigation | Upstream timeout, unhandled rejection, data inconsistency |
| fatal | System cannot continue | Database connection lost, out of memory, config missing |
What to NEVER Log
- Passwords, tokens, API keys, session IDs
- Full credit card numbers, SSNs, or PII
- Request/response bodies containing user data (log a hash or ID instead)
- Conversation or message content
Correlation IDs
- Generate a unique ID at the entry point (API gateway, message consumer)
- Pass it through every function call, database query, and outgoing HTTP request
- Include it in every log line and error response
- Return it to the client for support reference
Health Check Endpoints
Liveness (/health/live)
Returns 200 if the process is running. No dependency checks.
Readiness (/health/ready)
Returns 200 only if all critical dependencies are reachable:
{
"status": "healthy",
"checks": {
"database": { "status": "up", "latency_ms": 12 },
"cache": { "status": "up", "latency_ms": 3 },
"upstream_api": { "status": "up", "latency_ms": 89 }
}
}Alerting Thresholds
| Metric | Warning | Critical | Action |
| Error rate (5xx) | > 1% of requests | > 5% of requests | Page on-call |
| Latency (p95) | > 500ms | > 2000ms | Investigate |
| Queue depth | > 1000 | > 10000 | Scale consumers |
| Disk usage | > 80% | > 95% | Expand storage |
| Memory usage | > 85% | > 95% | Investigate leaks |
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.

