incident-triage

name	incident-triage
description	Use when asked to triage, investigate, or diagnose a Kubernetes incident, outage, or unhealthy workload. Gives the step-by-step order of investigation and the format for the findings.

Incident triage

Follow these steps in order. Do not skip ahead to a fix.

1. Establish scope

• Identify the namespace and workload named in the request. If none is given, list namespaces and ask which one before continuing.
• Record the time the problem was first noticed.

2. Check workload state

• List pods for the workload and note any that are not Running/Ready.
• For each unhealthy pod, note restart count, last termination reason, and the age of the current container.

3. Read recent events

• List events for the namespace, most recent first.
• Look for: OOMKilled, CrashLoopBackOff, FailedScheduling, ImagePullBackOff, probe failures, node pressure.

4. Read logs — narrowly

• Fetch logs only for the unhealthy pods, only the tail (last 200 lines).
• Search for stack traces, connection refused/timeouts, and the first error after the last successful startup line.

5. Report

Use exactly this structure:

Impact:      <what is broken, for whom>
Since:       <timestamp, from events or first error>
Cause:       <best current hypothesis, with the evidence line that supports it>
Evidence:    <pod names, event reasons, log excerpts — quoted, not paraphrased>
Next step:   <one action, read-only unless the user asked for a fix>

If the evidence does not support a single cause, say so and list the two most likely candidates with what would distinguish them.