Log analysis to find the cause of an incident

You are a site reliability engineer investigating an incident. Analyze the logs below.

Symptom reported: [e.g. "checkout returned 502 errors for about 20 minutes"]
When it started and ended (with time zone): [TIMES]
System overview: [SERVICES INVOLVED AND HOW THEY CONNECT]
Recent changes: [DEPLOYS, CONFIG CHANGES, TRAFFIC EVENTS, OR "unknown"]

Logs (time-ordered if possible; note the source of each block):
"""
[PASTE LOG EXCERPTS]
"""

Please:
1. Build a timeline of significant events, citing the exact log line for each.
2. Identify the earliest event that looks abnormal, and explain why it is abnormal rather than background noise.
3. Give up to four hypotheses for the root cause, ranked by likelihood. For each: supporting evidence (quoted lines), evidence against, and what is missing.
4. For each hypothesis, suggest the next check: a log query, metric, command or config to inspect.
5. Separate symptoms (timeouts, retries, 5xx) from likely causes.
6. Say clearly if the logs are insufficient to decide.

Do not state a root cause as fact unless the logs show it directly.

Example (excerpt):
Timeline:
14:02:11 payments-api deploy v2.8.0 completed ("Deployment finished" line)
14:03:40 first "connection pool exhausted (max=10)" from payments-api
14:03:45 checkout-web starts logging "upstream 502 from payments-api"
Earliest anomaly: pool exhaustion 89 seconds after the deploy.
Hypothesis 1 (likely): v2.8.0 reduced the database pool size or leaks connections. Against: no config diff provided.
Next check: compare DB_POOL_SIZE between v2.7.4 and v2.8.0 and graph active DB connections from 13:55.

When to use it

Use this prompt during or after an outage, when you have thousands of log lines and need to know where to look first. It also helps when writing a post-incident review, because the timeline and quoted evidence become the backbone of the report.

During a live incident, restoring service comes first: if a recent deploy is the obvious suspect and rolling it back is safe, do that, then use the prompt to understand what happened. The analysis is only as good as the excerpt you provide, so include lines from every service on the request path, not just the one that showed the error.

How to customize it

• [SYMPTOM] anchors the analysis on what users actually experienced.
• [TIMES] with a time zone prevent confusion between UTC server logs and local reports.
• [SYSTEM OVERVIEW] lets the model reason about how a failure in one service shows up in another.
• [RECENT CHANGES] are the most common cause of incidents, so list every deploy and config change you know about.
• [LOGS] should include a few minutes before the start. Remove tokens, emails and other personal data first.

Why it works

Incidents are full of loud symptoms: retries, timeouts and error spikes in every downstream service. Asking for the earliest anomaly and separating symptoms from causes pushes the analysis upstream, where the fix usually is.

Ranked hypotheses with evidence for and against mirror good debugging practice and avoid locking onto the first plausible story. Requiring quoted lines makes every claim checkable, and the explicit permission to say “insufficient data” reduces confident guesses. The suggested next checks keep the investigation moving.

Tips and variations

• Paste logs from several services in separate labelled blocks so the model can correlate them.
• Feed back the result of each check and ask for an updated ranking.
• If your logs are huge, filter by time window and severity first, or let an assistant that can run code parse the files.
• For bugs you can reproduce, switch to the debugging assistant prompt.
• Read our guide on LLM observability if the incident involves an AI feature.