Log Analyzer

The Problem

Application logs grow to thousands of lines fast. Scrolling through raw log output hunting for the one error that matters wastes valuable debugging time. Patterns like cascading failures, memory leaks, and rate limit hits hide in plain sight across hundreds of lines that a human eye easily skips.

The Prompt

You are a senior DevOps engineer specializing in log analysis. Analyze the following logs:

LOGS:
[paste your log output here — include timestamps, levels, and messages]

CONTEXT:
- Application: [e.g., Node.js Express API, Django backend, Kubernetes pod]
- Issue reported: [e.g., "API responses slow after 2am", "intermittent 502 errors"]

Provide:
1. **Error Summary**: List all unique errors with count and first/last occurrence
2. **Timeline**: Chronological sequence of events leading to the issue
3. **Patterns**: Any recurring patterns (periodic failures, escalating errors, correlated events)
4. **Root Cause Analysis**: Most likely root cause based on the evidence
5. **Anomalies**: Anything unusual that doesn't fit the expected pattern
6. **Recommended Fix**: Concrete steps to resolve the identified issue
7. **Monitoring Suggestion**: What alert or metric would catch this earlier next time

Example Output

Error Summary:
- ECONNREFUSED 127.0.0.1:6379 (Redis) — 47 occurrences, first at 02:14:03, last at 02:31:17
- TimeoutError: Response exceeded 30000ms — 12 occurrences, first at 02:15:01
- ENOMEM: JavaScript heap out of memory — 1 occurrence at 02:31:17

Timeline:
02:14:03 — Redis connection drops (likely restart or OOM kill)
02:14:03-02:15:01 — Application retries Redis, falls back to database
02:15:01 — Database overwhelmed by cache-miss traffic, responses timeout
02:31:17 — Node.js process crashes with OOM due to queued retry buffers

Root Cause: Redis process was killed (likely by OS OOM killer), causing a
cache stampede that overwhelmed the database and eventually crashed the app.

When to Use

Use this skill when debugging production incidents, investigating performance degradation, or reviewing logs after a deployment. It works best when you provide a continuous block of logs around the time of the incident rather than cherry-picked lines.

Pro Tips

• Include at least 5 minutes before the incident — the root cause often appears in the logs well before the visible symptoms start.
• Preserve timestamps and log levels — stripping metadata makes pattern detection significantly harder for the AI.
• Sanitize sensitive data — replace API keys, user emails, and passwords with placeholders like [REDACTED] before pasting logs into any AI tool.