Implement Error Tracking and Monitoring

Error Tracking and Monitoring is a skill that positions the model as an error tracking and observability expert. It sets up error tracking systems, configures alerts, implements structured logging, and helps teams identify and resolve production issues quickly. The stated focus is real-time error detection, meaningful alerts, error grouping, performance monitoring, and integration with popular error tracking services.

The core workflow has four steps: assess current error capture, alerting and grouping; define severity levels and triage workflows; configure logging, tracing and alert routing; and validate signal quality with test errors. A detailed implementation playbook backs this with eight areas.

1. Error tracking analysis: a Python ErrorTrackingAnalyzer that analyzes a codebase's error handling and logging.
2. Service integration: a Sentry setup in Node.js (DSN, environment and release, trace and profile sample rates, HTTP, Express, Postgres, MySQL and Mongo integrations, profiling), plus a custom TypeScript ErrorTracker with a batched event queue whose events carry level, message, stack, context, tags and a fingerprint.
3. Structured logging: a winston-based StructuredLogger with JSON output, default metadata for service, environment and version, console output in development, rotating error and combined log files, and an optional Elasticsearch transport.
4. Alerting: an AlertManager with rules for high error rate, response time degradation, memory usage and low disk space, each with a threshold, window, severity, channels and cooldown, and a Slack alert channel.
5. Grouping and deduplication: an ErrorGrouper that normalizes numbers, UUIDs, URLs, file paths, memory addresses and timestamps to build a fingerprint and find similar groups.
6. Performance impact tracking: a PerformanceMonitor that collects response time, error rate, throughput, Apdex and resource usage per service.
7. Recovery: a RecoveryManager with strategies for network, database, rate-limit and external-service errors, using retry with backoff and a circuit breaker with fallback.
8. A React error dashboard with time ranges from 1h to 30d and cards for error rate, total errors, affected users and MTTR.

The playbook's specifics give a concrete starting point. The Sentry setup defaults trace and profile sampling to 10 percent, strips request cookies and drops debug-level console breadcrumbs in beforeSend, attaches stack traces, keeps up to 100 breadcrumbs, tags events with component and version, captures uncaught exceptions as fatal and unhandled promise rejections with a graceful shutdown, builds a custom fingerprint from error name, location and code, and captures 4xx and 5xx errors from Express. The custom tracker batches 10 events and flushes every 5 seconds. Log files rotate at 5MB with up to 5 files kept. The example alert rules are a 5 percent error rate over 5 minutes (critical, Slack and PagerDuty), p95 response time over 1 second for 10 minutes (warning), memory above 90 percent for 5 minutes (critical), and free disk below 10 percent for 15 minutes (warning, Slack and email), with a 15 minute default cooldown. Recovery policies retry network errors 3 times with backoff from 1 to 10 seconds, retry database errors twice (trying a read replica first for reads), wait out the retry-after period on rate limits, and route external service calls through a circuit breaker with an optional fallback. The dashboard refreshes every 30 seconds and marks the error rate critical above 5 percent.

The alert rules are expressed as a small dataclass:

@dataclass
class AlertRule:
    name: str
    condition: str
    threshold: float
    window: timedelta
    severity: str
    channels: List[str]
    cooldown: timedelta = timedelta(minutes=15)

Use it when implementing or improving error monitoring, configuring alerts, grouping and triage workflows, or setting up structured logging and tracing.

Do not use it when the system has no runtime or monitoring access, when the task is unrelated to observability or reliability, or when you only need a one-off bug fix. Two safety rules apply throughout: avoid logging secrets, tokens or personal data, and use safe sampling to prevent overload in production. The skill also says not to treat its output as a substitute for environment-specific validation, testing or expert review, and to stop and ask when required inputs, permissions, safety boundaries or success criteria are missing.

The input is the user's requirements, passed in as the skill's arguments, together with access to the system's current error capture, alerting and logging setup. The outputs are a monitoring design and configuration: severity levels and triage workflows, logging and tracing configuration, alert routing, and implementation code drawn from the playbook. The skill asks you to validate signal quality with test errors rather than assume the pipeline works.

Engineering teams that need to implement or improve production error monitoring, structured logging and alerting, and want a starting set of patterns for each.