error-handler

Implement OpenTelemetry error handling with structured logging and burn-rate alerts.

110|14|Updated May 12, 2026
One-click install
npx skills add https://github.com/EliasOulkadi/shokunin --skill error-handler-eliasoulkadi
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: error-handler
Source: https://github.com/EliasOulkadi/shokunin/tree/main/.pack/skills/error-handler
Command: npx skills add https://github.com/EliasOulkadi/shokunin --skill error-handler-eliasoulkadi

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve?

This Skill helps engineers turn scattered failures into reliable, production-grade error handling with consistent structured logs, OpenTelemetry tracing/metrics/logs, clear error classification, and SLO-driven alerting.

Core Features & Use Cases

  • Error classification & alert priority: Maps common HTTP error categories to severity, log level, and SLO impact (e.g., 4xx vs 5xx and downstream/timeout cases).
  • OpenTelemetry instrumentation & correlation: Sets up an OTEL SDK exporting traces/metrics/logs and enforces correlation using shared trace_id/span_id across signals.
  • Recovery patterns for reliability: Implements retry with exponential backoff + jitter, circuit breaker, and timeouts, including guardrails for retryable vs non-retryable errors.
  • Error budgets and burn-rate alerts: Defines SLO/error budget targets and provides PromQL burn-rate alerting logic to drive incident prevention and triage.
  • Use case: When a checkout API starts failing intermittently, use this Skill to classify errors, ensure logs and traces link to the same request, apply safe recovery patterns to downstream calls, and page based on multi-window burn-rate signals rather than guesswork.

Quick Start

Ask the agent to implement OpenTelemetry-based error classification, structured JSON error logging with trace correlation, and recovery patterns (retry with jitter, circuit breaker, and timeouts) for your Node/TypeScript service, then add error budget burn-rate alert rules for your 99.9% SLO.

Frequently Asked Questions about error-handler

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

FAQPage Schema
How do I implement OpenTelemetry trace correlation with structured JSON logging for backend error handling?

OpenTelemetry trace correlation with structured logging uses a JSON schema embedding trace_id, span_id, and request_id to unify logs, traces, and metrics across the request lifecycle for reliable production triage.

What's the best way to set up retry with exponential backoff and circuit breaker patterns for downstream API calls?

Implementing retry with exponential backoff and jitter alongside circuit breaker patterns requires gating retries by error classification to safely recover from downstream failures without overwhelming dependencies or retrying non-retryable errors.

How do I configure PromQL burn-rate alerting rules for SLO error budgets?

PromQL burn-rate alerting rules for SLO error budgets use multi-window burn-rate signals to page on defined SLO targets like 99.9%, replacing guesswork with reliable incident prevention and triage.

How does error classification map HTTP status codes to severity levels and SLO impact?

Error classification maps HTTP categories to severity, log level, and SLO impact, differentiating 4xx client errors from 5xx server or downstream timeout cases to prioritize alerting and incident response.

Do I need an OpenTelemetry SDK setup with sampling strategy before implementing production error handling?

An OpenTelemetry SDK setup with a defined sampling strategy is required to export correlated traces, metrics, and logs consistently across request lifecycles before building reliable production error handling.

Why should I use multi-window burn-rate alerts instead of simple error rate thresholds for incident triage?

Multi-window burn-rate alerts measure error budget consumption against SLO targets over different time windows, preventing false alarms from transient spikes while quickly catching sustained failures during incident triage.