triage-unhealthy-workload

You can triage a Kubernetes workload stuck in CrashLoopBackOff by composing doctor, explain, and trace steps to collect read-only cluster evidence and produce an evidence-backed explanation of what is broken and why.

Your Argo CD or Flux GitOps rollout may show a health failure due to manual configuration drift or missing secret dependencies preventing pods from starting. The triage workflow traces the delivery chain to attribute the root cause.

To diagnose missing secret resolution issues, the triage process surfaces secret attribution data and highlights missing dependencies that often prevent pods from starting, pointing you to the next read-only checks.

Yes, you can use this triage process during an active incident because it enforces strict safety boundaries by supporting only targeted read-only kubectl evidence collection, ensuring it avoids mutating cluster state.

The best way to identify ownership and configuration drift for a failing Kubernetes resource is to run the triage workflow, which surfaces which controller owns the resource and whether the cause looks like manual edits or drift.

Yes, the Kubernetes triage workflow supports tracing resources provisioned by Crossplane or Helm by attributing the source delivery chain across Argo CD, Flux, Helm, and Crossplane to pinpoint the origin of the failure.