Error Monitoring

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