Error Monitoring

Overview

This skill helps you analyze application errors from monitoring platforms. It processes error exports, groups events by root cause, identifies duplicates, and classifies errors by user impact — turning a chaotic error stream into an actionable triage report.

Instructions

When the user provides error data (JSON export, CSV, or pasted logs), follow this process:

1. Parse and Normalize

• Accept Sentry JSON exports, Datadog event logs, generic JSON arrays, or CSV files
• Extract key fields: error message, stack trace (top frame), timestamp, occurrence count, status, affected users
• Normalize error messages by stripping variable parts (IDs, timestamps, file paths) to find true duplicates

2. Group by Root Cause

• Cluster errors that share the same stack trace origin (file + line + function)
• Merge errors with identical normalized messages even if stack traces differ slightly
• Flag groups that are likely the same root cause but reported under different names

3. Assess Impact

For each error group, determine:

• Frequency: events per day (average and trend — increasing, stable, decreasing)
• User reach: unique users affected (if available)
• Severity signals: look for keywords indicating data loss, payment failure, auth issues, or security concerns
• Self-healing: does the error auto-resolve? (check if occurrences are followed by long gaps)

4. Produce the Report

Output a structured report with:

• Total events analyzed, time range, unique error groups
• Top error groups ranked by volume, with: message, source location, event count, percentage of total, first/last seen, impact assessment
• Duplicate groups (errors that should be merged)
• Resolved-but-recurring groups (marked resolved but still firing)
• Recommended priority: P1 (immediate), P2 (soon), P3 (backlog)

Examples

Example 1: Sentry JSON Export Analysis

Input: User provides

errors-export.json

with 3,200 error events from the last 14 days.

Output:

Error Analysis — 14-Day Window
Total Events: 3,200 | Unique Groups: 47 | Time Range: Jan 3 – Jan 17

Top 5 Error Groups:

1. [P3] TypeError: Cannot read property 'name' of null
   Source: src/components/UserCard.tsx:89
   Events: 812 (25.4%) | Users: 34 | Trend: Stable
   Note: Occurs on profile preview for deleted accounts. No data loss.

2. [P1] DatabaseError: deadlock detected
   Source: src/services/order.ts:201
   Events: 156 (4.9%) | Users: 89 | Trend: Increasing (+40% week-over-week)
   Note: Causes failed order submissions. Revenue impact confirmed.

3. [P2] FetchError: network timeout at /api/inventory
   Source: src/lib/api-client.ts:45
   Events: 340 (10.6%) | Users: 201 | Trend: Decreasing
   Note: Correlates with deployment windows. Likely cold-start related.

Duplicates Found:
- Groups #12 and #31 share identical root cause (different error wrappers)
- Groups #8, #19, #22 all stem from expired JWT tokens

Resolved But Recurring:
- Group #5 (CORS error) was resolved on Jan 10 but has 45 new events since

Example 2: CSV Log File

Input: User provides

app-errors.csv

with columns: timestamp, level, message, stack_trace, user_id.

Output: Same structured report format, noting that CSV data lacks occurrence counts so each row is treated as one event.

Guidelines

• Always show percentages alongside raw counts — "812 events" is less useful than "812 events (25.4%)"
• When stack traces are missing, fall back to error message similarity for grouping
• Flag any error containing "payment", "auth", "password", "delete", or "drop" as potentially high-severity regardless of volume
• If the export is very large (>10,000 events), summarize the top 20 groups and offer to drill into specific ones
• Never assume an error is low-priority just because it's old — check if it's trending upward
• Recommend merging duplicate groups to reduce alert noise before any rule changes