What this prompt does
This prompt makes the AI an expert at log analysis that works backward from symptoms to root cause. You describe the [problem_description], the [timeline] of when it started, paste your [log_data], and give the [tech_stack] and [recent_changes], and it performs a six-step investigation: log pattern analysis, ranked root-cause hypotheses, diagnostic commands, missing-information gaps, a fix recommendation, and logging improvement suggestions. It is structured to find the first error in a sequence, not the loudest most recent one.
The structure works because it imposes incident discipline. It categorizes each entry by level, builds a timeline of events leading to failure, and flags unusual frequency spikes and correlated events. It then presents the top three hypotheses ranked by likelihood with supporting evidence and a confidence percentage, and gives concrete diagnostic commands to confirm or rule out each one (the example commands use your [condition] and [command] placeholders). The fix section separates immediate mitigation from the proper fix and prevention, and [log_format] guides the logging improvements left behind.
When to use it
- A production incident is live and the logs are too noisy to read by eye
- You keep fixing the most recent error instead of the actual root cause
- You want ranked hypotheses with evidence rather than one confident guess
- You need diagnostic commands to confirm or rule out each theory
- You want immediate mitigation separated from the durable fix
- You want concrete logging improvements so the next incident is faster to debug
Example output
You get a categorized log breakdown with a failure timeline, three ranked root-cause hypotheses each with supporting log evidence and a confidence percentage, per-hypothesis diagnostic commands, a list of missing data that would narrow things down, a three-part fix (mitigation, root-cause fix, prevention), and specific structured-logging improvements for the affected code paths.
Pro tips
- Paste real
[log_data]; the analysis is only as good as the lines you give it, so include the window around the failure - Be precise in
[timeline], since "started at 14:30, no deploy since" rules out whole classes of cause - Always fill
[recent_changes]honestly; a deploy 18 hours earlier is a prime suspect even if it feels unrelated - Set
[tech_stack]accurately so the diagnostic commands target your real services - Use
[log_format]to match your stack (structured JSON via Monolog) so improvement suggestions are actionable - Run the diagnostic commands to confirm a hypothesis before applying its fix; confidence percentages are estimates, not proof
