What this prompt does
This prompt feeds application logs to Gemini and runs a full incident analysis for a [incident_type] over a [time_window]. It reconstructs the timeline from first anomaly through cascade to resolution, identifies error patterns and frequencies, runs root-cause analysis with your [analysis_method], maps blast radius, correlates events across [log_sources], measures metric deviation from baseline, and recommends [fix_count] fixes. It then drafts a post-mortem in [report_format] and suggests runbook and alerting improvements.
The structure works because incident response is about reconstructing order and causality under time pressure. Building the timeline first gives every later step an anchor. The [analysis_method] (like 5 Whys) frames the root-cause reasoning, [log_sources] tells it which streams to correlate, and [severity_levels] standardizes how it classifies impact. The truncation clause asks it to name missing data instead of fabricating a complete story.
When to use it
- Something broke in production and you need a timeline and root cause fast
- You're correlating events across
[log_sources]like app logs, slow query logs, and nginx access logs - You need a post-mortem drafted in the stressful first hour of an incident
- You want detection gaps surfaced — which alerts should have fired but didn't
- You need
[fix_count]recommended fixes split into immediate and long-term - You want runbook updates captured while the incident is fresh
Example output
Expect a reconstructed timeline, an error-pattern frequency breakdown, a root-cause analysis using your [analysis_method], a blast-radius map, cross-source event correlation, metric deviations from baseline, a prioritized fix list, alerting suggestions, a post-mortem in [report_format], and runbook updates. Where logs are truncated, it names the additional data that would sharpen the analysis.
Pro tips
- Include all relevant
[log_sources]— correlation across app, database, and nginx logs is where the real root cause usually hides - Treat the
[analysis_method]output (5 Whys) as a hypothesis to confirm with metrics, not a final verdict - Set
[time_window]tight around the incident; too wide and the timeline drowns in noise - Use
[severity_levels]matching your on-call conventions so the classification maps to your runbooks - Ask for immediate and long-term fixes via
[fix_count]so you get a hotfix and a real remediation, not just one - Capture the runbook updates immediately — they're most accurate while the incident is fresh in the logs
