Chain-of-Thought Log Analysis and Anomaly Detection Prompt

This prompt is built for a specific job-to-be-done: a Site Reliability Engineer (SRE) or on-call operator is staring at a time-bounded window of logs, armed with a known symptom (e.g., 'payment API 503 errors spiked at 14:03 UTC'), and needs an auditable chain of reasoning to converge on a root cause before escalating or remediating. The ideal user is someone who understands the system's architecture but needs the model to systematically connect observed log patterns to plausible hypotheses, rule out false leads, and produce a traceable evidence-to-conclusion report. It is not a replacement for real-time alerting pipelines, nor is it a substitute for a human's final judgment in high-severity incidents. Instead, it serves as an investigative reasoning tool that accelerates the 'what happened and why' phase of post-hoc analysis.

To use this prompt effectively, you must provide a well-scoped context: a specific time window, a clear symptom or alert definition, and raw or pre-processed log lines. The prompt's value collapses without these inputs. For example, feeding it an unbounded stream of logs with no symptom will produce a generic summary, not a targeted root cause analysis. The model is instructed to produce a step-by-step reasoning trace, which means you should expect an output that explicitly states each hypothesis, the evidence that supports or refutes it, and the logical path to the final conclusion. This traceability is the core deliverable—it allows a human reviewer to audit the model's reasoning, challenge weak links, and use the output as evidence in an incident postmortem. In high-risk or regulated environments, this audit trail is non-negotiable; the prompt is designed to produce it, but a human must still sign off on the final determination before any irreversible remediation action is taken.

Do not use this prompt when you need a real-time alerting decision, when the log data is incomplete or heavily sampled, or when the incident is actively unfolding and requires immediate human coordination. The prompt is designed for post-hoc analysis where the full log window is available and the priority is correctness over speed. Also avoid using it for non-technical log sources (e.g., business process logs without clear causal structure) or when the system's architecture is entirely unknown to the operator—the model cannot reason about components it has no context for. If you find yourself needing to investigate an incident that spans multiple services with complex, non-linear dependencies, consider pairing this prompt with a dependency mapping or tree-of-thought exploration prompt to first model the system's failure domains before diving into log-level reasoning.

This section provides the core prompt template for the Chain-of-Thought Log Analysis and Anomaly Detection workflow. It is designed to be pasted directly into your AI harness, with square-bracket placeholders that you must replace with real values before execution. The prompt instructs the model to reason step-by-step through log data, connecting observed patterns to potential hypotheses, ruling out false leads, and converging on a root cause explanation. This structured reasoning trace is what makes the output auditable and trustworthy for operational use.

textCopy
You are a senior SRE performing a chain-of-thought analysis of system logs to detect and explain anomalous behavior.

Your task is to analyze the provided log entries, reason step-by-step through the evidence, and produce a final root cause analysis.

Follow this reasoning structure in your response:
1.  **Initial Observation:** Summarize the key anomalous patterns, errors, or spikes you see in the logs.
2.  **Hypothesis Generation:** List 2-3 plausible hypotheses that could explain the observed patterns.
3.  **Evidence Evaluation:** For each hypothesis, walk through the log data to find supporting or contradicting evidence. Explicitly rule out hypotheses that don't fit the evidence.
4.  **Causal Chain:** For the most likely hypothesis, construct a step-by-step causal chain from the triggering event to the observed symptoms, citing specific log lines as evidence for each link.
5.  **Root Cause Conclusion:** State the most probable root cause, your confidence level (High/Medium/Low), and any unresolved questions that require further investigation.

**Input Log Data:**
[LOG_DATA]

**System Context:**
[SYSTEM_CONTEXT]

**Known Baselines:**
[BASELINE_METRICS]

**Constraints:**
- Only use the provided log data as evidence. Do not invent facts.
- If the evidence is insufficient to reach a High-confidence conclusion, state that clearly and specify what additional data is needed.
- Flag any assumptions you are making.

To adapt this template, replace the [LOG_DATA], [SYSTEM_CONTEXT], and [BASELINE_METRICS] placeholders with your specific information. The [LOG_DATA] should be the raw or pre-filtered log lines you are investigating. [SYSTEM_CONTEXT] is a brief description of the service architecture, its dependencies, and recent changes. [BASELINE_METRICS] provides normal operating parameters to help the model distinguish anomalies from standard fluctuations. For high-risk production environments, always pair this prompt with an evaluation step that checks the traceability of each conclusion back to a specific log line, and require human review before any remediation action is taken based on the AI's analysis.

This prompt is designed to be embedded in an incident response pipeline, not used as a standalone chat interaction. The harness must enforce a strict contract: the model receives structured log evidence and returns a traceable hypothesis chain, not a conversational summary. Wire the prompt as a dedicated step in your alerting or on-call toolchain—triggered by anomaly detection systems, manual SRE invocation, or automated runbook execution—with the output feeding directly into an incident document or remediation decision record.

Input assembly requires extracting a time-bounded log window from your observability stack (Splunk, Datadog, Grafana Loki, Elasticsearch) and formatting it into the [LOG_WINDOW] placeholder. Include service name, time range, and raw log lines. The [SYSTEM_CONTEXT] placeholder should carry architecture metadata: service dependency graph, recent deployments, known error signatures, and baseline metrics. Model selection favors models with strong reasoning benchmarks (Claude 3.5 Sonnet, GPT-4o, Gemini 2.0 Flash Thinking) and long context windows—log windows can easily exceed 50k tokens. Set temperature to 0 or near-zero to maximize deterministic reasoning. Tool integration is optional but powerful: provide a search_documentation tool for the model to query runbooks, or a query_metrics tool to pull time-series data that contextualizes the log patterns. If using tools, add a [TOOLS] section to the prompt with function schemas and usage constraints.

Validation and retry logic must operate on the structured output. Parse the JSON response and run three checks before accepting the analysis: (1) every hypothesis step references at least one log line or evidence source, (2) the root cause candidate includes explicit confidence indicators and unresolved questions, and (3) the output schema is fully populated with no truncated fields. If validation fails, retry once with the validation errors injected into the [PREVIOUS_ATTEMPT_FEEDBACK] field. After two failures, escalate to a human on-call with the partial analysis and raw logs. Human review gates are mandatory for high-severity incidents (SEV1/SEV2). Route the model's output to an incident commander with a structured review prompt that asks: 'Does the evidence chain support the conclusion? Are there alternative hypotheses not explored? Should we act on this root cause now or gather more data?'

Logging and observability for the prompt itself is critical. Record the full prompt payload, model response, validation results, and human review decision in your incident management system (PagerDuty, FireHydrant, ServiceNow). Tag each analysis with the prompt version, model identifier, and latency metrics. This audit trail enables post-incident review of AI-assisted diagnosis quality and provides training data for future prompt improvements. Avoid wiring this prompt directly to automated remediation actions—the output is a diagnostic hypothesis, not an execution command. Always require explicit human approval before running fix actions based on the model's root cause analysis, especially for database changes, infrastructure modifications, or customer-facing configuration updates.