dev-error-handling

Implements retry, circuit breaker, timeout, and structured error handling patterns for TypeScript services.

3|3|Updated Apr 23, 2026
One-click install
npx skills add https://github.com/joaoguirunas/team-os --skill dev-error-handling-joaoguirunas
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dev-error-handling
Source: https://github.com/joaoguirunas/team-os/tree/main/.claude/skills/dev-error-handling
Command: npx skills add https://github.com/joaoguirunas/team-os --skill dev-error-handling-joaoguirunas

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires pino.

What problem does it solve? Applications that call databases, external APIs, and third-party services fail unpredictably, and unhandled failures cause cascading outages, leaked stack traces, and undebuggable production errors. This Skill provides concrete TypeScript patterns for building resilient services that degrade gracefully instead of crashing. ## Core Features & Use Cases - Retry with Exponential Backoff: Wrap transient external calls with configurable retry logic, jitter, and 4xx short-circuiting. - Circuit Breaker & Timeouts: Stop cascading failures with a CLOSED/OPEN/HALF_OPEN state machine and enforce explicit timeouts on every external call. - Typed Errors & Structured Logging: Use AppError subclasses, an Express error boundary, and pino-based logging with requestId for end-to-end traceability. - Use Case: When integrating a payment API, wrap the call with a 5-second timeout, retry only on 5xx/network errors, and return a typed ExternalServiceError with the requestId so support can trace the failure without reproducing it. ## Quick Start Apply the dev-error-handling patterns to add retry, timeout, and a typed error boundary to my Express payment endpoint.

Frequently Asked Questions about dev-error-handling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement retry with exponential backoff in TypeScript?▼

Wrap the async call in a loop that retries up to maxAttempts, doubling the delay each attempt (300ms, 600ms, 1200ms) plus random jitter. Skip retries for 4xx client errors since they are not transient failures.

How does a circuit breaker prevent cascading failures?▼

A circuit breaker tracks consecutive failures and opens after a threshold (e.g., 5 failures), rejecting calls immediately instead of hitting a down service. After a cooldown timeout it enters HALF_OPEN to test recovery before closing again.

Should I retry requests that return 4xx errors?▼

No, 4xx errors indicate client-side problems like invalid input or missing auth, so retrying them wastes time and never succeeds. Retry only transient failures such as 5xx responses and network errors.

How do I add a global error handler in Express?▼

Register an error-handling middleware with four parameters (error, req, res, next) as the last middleware in the chain. Map typed AppError instances to their statusCode and code, and return a generic 500 for unknown errors without leaking internals.

Why should error responses include a requestId?▼

A requestId links API error responses to structured server logs, enabling end-to-end traceability across services. It lets you debug production failures from a single identifier without reproducing the issue.

When should I use graceful degradation instead of failing the request?▼

Use graceful degradation for non-critical dependencies, such as loading user preferences, where a default fallback keeps the core response working. Reserve hard failures for critical resources like the primary database record.