Kubernetes Pod CrashLoop Analysis Prompt

This prompt is designed for platform engineers and SREs who need to move from raw diagnostic data to a structured root cause analysis when a pod is stuck in a CrashLoopBackOff state. The job-to-be-done is systematic differential diagnosis: you have already gathered the evidence—kubectl describe pod output, container logs, exit codes, resource configurations, and liveness probe definitions—and you need to synthesize that evidence into a ranked list of probable causes with specific, copy-pasteable remediation commands. The ideal user understands Kubernetes primitives and can validate the model's reasoning against their own cluster state, but wants to accelerate the correlation step that connects symptoms to root causes.

You should use this prompt when you have a complete diagnostic snapshot and need a structured analysis artifact for a post-incident review, a runbook entry, or a handoff to another engineer. The prompt expects placeholders for [POD_DESCRIBE_OUTPUT], [CONTAINER_LOGS], [EXIT_CODE], [RESOURCE_LIMITS], [LIVENESS_PROBE_CONFIG], and [NAMESPACE_CONTEXT]. Do not use this prompt for live incident response where a human must make time-critical decisions without review; the output requires validation before any remediation commands are executed. The prompt is also not a substitute for real-time monitoring or alerting—it is a post-hoc analysis tool, not a detection system.

Before executing any remediation commands produced by this prompt, validate them against your cluster's current state, RBAC permissions, and change management policies. The prompt's output is a hypothesis, not a guarantee. Common failure modes include misattributing an OOMKill to a memory leak when the real cause is a misconfigured limit, or recommending a liveness probe delay increase that masks a deeper initialization race condition. Always correlate the model's findings with your own timeline of events and consider running the analysis in a read-only context before applying fixes. For high-severity production incidents, the output should be reviewed by a second engineer before any action is taken.

This prompt template is designed to be pasted directly into your AI harness or orchestration layer. It accepts structured diagnostic data collected from a Kubernetes cluster and returns a root cause analysis with specific remediation commands. Replace each square-bracket placeholder with real data before execution. The prompt enforces a strict output schema so that downstream tooling—such as ticketing systems, runbook automation, or incident postmortems—can consume the result without manual reformatting.

textCopy
You are a senior platform engineer diagnosing a Kubernetes pod stuck in CrashLoopBackOff.

Analyze the following diagnostic data and return a structured root cause analysis.

[POD_MANIFEST]

[POD_EVENTS]

[PREVIOUS_CONTAINER_LOGS]

[CURRENT_CONTAINER_LOGS]

[NODE_RESOURCE_UTILIZATION]

[LIVENESS_PROBE_CONFIG]

[READINESS_PROBE_CONFIG]

[EXIT_CODES]

[RESTART_COUNT]

[CLUSTER_EVENTS]

[OUTPUT_SCHEMA]
Return a JSON object with these exact fields:
- "primary_root_cause": string (the single most likely cause)
- "confidence": "high" | "medium" | "low"
- "evidence": array of strings (specific log lines, event messages, or config values that support the root cause)
- "alternative_hypotheses": array of { "cause": string, "likelihood": "high" | "medium" | "low", "evidence_for": array of strings, "evidence_against": array of strings }
- "remediation_steps": array of { "action": string (a specific kubectl command, manifest change, or operational action), "expected_effect": string, "risk": "low" | "medium" | "high", "reversible": boolean }
- "missing_data": array of strings (diagnostic information that would increase confidence if collected)
- "prevention_recommendations": array of strings (long-term fixes to prevent recurrence)

[CONSTRAINTS]
- Do not speculate beyond the provided data. If evidence is insufficient, set confidence to "low" and list what is missing.
- Prefer exit codes and log messages over generic patterns.
- If the liveness probe configuration is the likely cause, explain the exact threshold mismatch.
- If resource limits are implicated, cite the specific limit and the observed utilization.
- Do not recommend deleting the pod as the only remediation step.
- If multiple causes are possible, rank alternative hypotheses by likelihood.

After pasting this template into your harness, replace each placeholder with real data collected from kubectl describe pod, kubectl logs, and your monitoring system. The [OUTPUT_SCHEMA] block is part of the prompt itself—it tells the model exactly what shape to return. Do not remove it. If your application layer already enforces a JSON schema via function calling or structured output mode, you can replace the inline schema with a reference to your tool definition. Always validate the returned JSON against the expected fields before surfacing remediation steps to an operator or executing them automatically. For production incident response, route any remediation step marked "risk": "high" or "reversible": false through a human approval queue before execution.

This prompt is designed to be called programmatically during an incident or as part of a post-incident review pipeline. The primary integration point is a backend service or an SRE bot that receives a pod identifier (namespace/name) and a time window, then fetches the required Kubernetes objects before assembling the prompt. The implementation harness must handle data gathering, prompt assembly, model invocation, output validation, and safe presentation of remediation commands. Because the output includes specific kubectl commands and configuration patches, the system should never auto-execute these commands without human review. The harness should treat the model output as a structured analysis artifact that informs a human operator's decision, not as an automated remediation script.

To wire this into an application, build a data-gathering function that runs kubectl or the equivalent Kubernetes API calls to collect: kubectl describe pod [POD_NAME] -n [NAMESPACE], kubectl logs [POD_NAME] -n [NAMESPACE] --previous --tail=200, kubectl get events -n [NAMESPACE] --field-selector involvedObject.name=[POD_NAME], and the pod's full YAML manifest. If the pod is managed by a Deployment, StatefulSet, or DaemonSet, also fetch the owning controller's manifest to capture liveness/readiness probe configurations, resource limits, and volume mounts. Package these into the [POD_DESCRIBE_OUTPUT], [PREVIOUS_CONTAINER_LOGS], [POD_EVENTS], and [POD_MANIFEST_YAML] placeholders. Set [TIME_WINDOW_MINUTES] based on the incident timeline. The harness should validate that all required inputs are non-empty before sending the prompt; if logs are missing because the container never started, populate the field with a note like `

No previous container logs available — container may be failing before log output begins."` This prevents the model from hallucinating log content."

For model choice, use a model with strong structured output capabilities and a context window large enough to hold the full manifest and log output. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are suitable. Set temperature to 0.1–0.2 to reduce variance in root cause classification. Request a JSON output schema matching the [OUTPUT_SCHEMA] defined in the prompt template, and implement a post-generation validation step that checks: (1) the root_cause_hypotheses array is non-empty, (2) each hypothesis has a non-empty evidence array with specific log lines or event timestamps, (3) remediation_steps contain actionable commands or configuration changes, and (4) the confidence_score is a float between 0.0 and 1.0. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_VALIDATION_ERRORS]. If the retry also fails, surface the raw output to a human reviewer with a clear flag that automated validation did not pass.

Log every invocation with the pod identifier, model version, prompt version, token usage, and validation result. This audit trail is critical for post-incident review and for debugging cases where the model misdiagnosed a CrashLoop. Store the structured output in the incident timeline or a dedicated analysis log so that SRE teams can correlate the AI-generated hypotheses with the actual root cause discovered during resolution. Over time, this log becomes a dataset for evaluating prompt accuracy and for fine-tuning if the team moves to a custom model. Avoid logging raw pod manifests that may contain secrets; redact env values and secretRef entries before persisting logs.

The highest-risk failure mode is the model generating plausible but incorrect remediation commands. A hallucinated kubectl patch or an incorrect resource limit adjustment can worsen an outage. The harness must render remediation commands in a read-only format with a clear warning that they require human review before execution. If integrating with a runbook automation system, add an explicit approval gate that requires an SRE to confirm each command. For configuration changes like liveness probe tuning or resource limit adjustments, the harness should generate a diff view against the current manifest and require a pull-request-style review before applying. Never wire this prompt directly to a kubectl apply call without human-in-the-loop approval.