Log Analysis Prompt for Claude: Find the Root Cause

When production breaks, the logs have the answer but also ten thousand lines of noise. This prompt makes Claude build a timeline, separate symptoms from causes, and give you ranked hypotheses with the next check for each, instead of a confident guess.

The prompt

You are a senior site reliability engineer helping during an incident. Be precise and skeptical: logs show symptoms, and correlation is not cause.

<context>
System: {{SYSTEM_DESCRIPTION}}
What users are seeing: {{SYMPTOM}}
When it started (if known): {{START_TIME}}
Recent changes (deploys, config, traffic, dependencies): {{RECENT_CHANGES}}
</context>

<logs>
{{LOG_EXCERPT}}
</logs>

<instructions>
1. Build a short timeline of significant events, with timestamps, in order. Mark the first anomaly.
2. Group errors by signature (same message or stack trace). For each group give count, first and last occurrence, and affected component.
3. Separate root-cause candidates from downstream symptoms (for example, timeouts caused by an upstream failure).
4. Give up to 3 hypotheses, ranked by likelihood. For each:
   - Evidence for (quote the exact log lines)
   - Evidence against or missing
   - One concrete check that would confirm or rule it out (a query, command, metric or file to look at)
5. Recommend an immediate mitigation only if the evidence supports it, and say what it would cost (e.g. rollback loses feature X).
6. List what other data would help most (another service's logs, metrics, a wider time window).
7. Do not invent log lines, services or metrics that are not in the input.
</instructions>

<output_format>
## Summary (2 sentences)
## Timeline
## Error groups (table)
## Hypotheses (ranked)
## Suggested mitigation
## Data to collect next
</output_format>

How to use it

• Prepare the logs first. Filter to the incident window, collapse duplicates, and redact secrets and personal data before sending anything. A quick pass with grep -v for health checks often cuts the volume in half.
• claude.ai: paste the excerpt and fill in the context. Recent deploys matter most; include the commit range if you have it.
• Claude Code: ask Claude to read the log export or run your log CLI, then apply the prompt. It can also open the code paths named in stack traces, which is where it beats a chat window. If you hit context limits on huge files, see the context management guide.
• Scripts: grep ERROR app.log | tail -500 | claude -p "$(cat log-prompt.txt)" gives a first read you can post to the incident channel. More in the headless mode guide.

Variables

Variable	What to put there
{{SYSTEM_DESCRIPTION}}	Services involved and how requests flow between them
{{SYMPTOM}}	What users or alerts report, in one or two lines
{{START_TIME}}	Approximate start, with time zone
{{RECENT_CHANGES}}	Deploys, flag flips, config changes, dependency upgrades
{{LOG_EXCERPT}}	Filtered, redacted log lines with timestamps

Example output (illustrative)

## Summary
Checkout errors began at 14:02 UTC, two minutes after deploy 7f3a. Most errors
are downstream timeouts; the first anomaly is a connection pool exhaustion
in orders-db.

## Hypotheses (ranked)
1. New query in 7f3a holds DB connections longer (likely)
   For: "pool exhausted (max=20)" from 14:02:11, first after deploy
   Against: no slow-query log included
   Check: compare p95 query time for orders before and after 14:00

Tips and variations

• Postmortem mode: after the incident, give Claude the timeline and chat log and ask for a blameless postmortem draft.
• Feed it the code: pair with the bug triage prompt once you’ve narrowed down the component.
• Make it a skill: if your team runs this every incident, save it as a skill with your log query baked in; see the Claude Code skills guide.
• More technique: Claude prompting best practices.