kubectl-investigator

Investigate Kubernetes incidents using a seven-step methodology with timelines and ranked hypotheses.

17|Updated May 15, 2026
One-click install
npx skills add https://github.com/anyshift-io/sre-skills --skill kubectl-investigator
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kubectl-investigator
Source: https://github.com/anyshift-io/sre-skills/tree/main/skills/kubectl-investigator
Command: npx skills add https://github.com/anyshift-io/sre-skills --skill kubectl-investigator

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

AI agents lack the structured methodology that seasoned SREs apply during live Kubernetes incidents. Without guardrails, they misclassify failures, miss critical signals, or recommend dangerous mitigations like unbounded rollbacks. This skill encodes a proven seven-step investigation playbook so agents triage incidents with the same rigor as a senior engineer, producing timelines, ranked hypotheses, and safe mitigation recommendations.

Core Features & Use Cases

  • Seven-step investigation methodology: Anchor the incident window, bisect the change surface, classify against four reference paths (OOM, DNS, cascading-failure, deploy-correlator), confirm with three independent signals, quantify blast radius, and propose mitigation before root cause.
  • Built-in escalation guards: Detects methodology-level failure modes (ambiguous T0, confirmation bias, asymmetric revert blast radius) and operational failure modes (missing telemetry, multi-incident interleaving) to force human escalation rather than force-fit a wrong answer.
  • Eleven fixture-tested worked examples: Covers canonical paths, escalation cases, and edge cases (zero-change windows, multi-region asymmetry, capacity-bound organic growth) with deterministic replay tests that run offline against committed telemetry snapshots.

Quick Start

Use the kubectl-investigator skill to investigate the current Kubernetes incident by following the seven-step methodology against your cluster telemetry and produce a structured handoff for the postmortem author.

Frequently Asked Questions about kubectl-investigator

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I investigate a Kubernetes incident methodically to find the root cause?

To investigate a Kubernetes incident methodically, you anchor the incident window, bisect the change surface, and classify failures against OOM, DNS, cascading-failure, and deploy-correlator paths to produce ranked hypotheses and mitigation recommendations.

What is the best way to triage OOM kills and DNS resolution failures in Kubernetes Deployments?

The best way to triage OOM kills and DNS resolution failures is classifying them against four reference paths, confirming with three independent signals, and quantifying the blast radius before proposing mitigation to ensure safe incident resolution.

How do I prevent dangerous unbounded rollbacks during a live Kubernetes incident investigation?

To prevent dangerous unbounded rollbacks during an investigation, use built-in escalation guards that detect asymmetric revert blast radius and force human escalation rather than force-fitting a wrong mitigation answer.

Does this Kubernetes investigation methodology work with StatefulSets, DaemonSets, and Jobs?

Yes, this Kubernetes investigation methodology works with StatefulSets, DaemonSets, and Jobs, applying to workload-level failures including OOM kills, DNS resolution failures, and cascading retry storms.

When should I escalate a Kubernetes incident investigation instead of forcing a root cause analysis?

You should escalate a Kubernetes incident investigation when encountering ambiguous T0, confirmation bias, missing telemetry, or multi-incident interleaving to prevent force-fitting incorrect root cause analysis answers.

Can I test my Kubernetes incident investigation methodology offline against committed telemetry snapshots?

Yes, you can test your investigation methodology offline using eleven fixture-tested worked examples with deterministic replay tests that run against committed telemetry snapshots for canonical paths and edge cases.