Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
fluxcd avatar

Gitops Cluster Debug

  • 533 installs
  • 202 repo stars
  • Updated August 4, 2026
  • fluxcd/agent-skills

gitops-cluster-debug is a Flux CD cluster troubleshooting skill that traces failing GitOps reconciliations on live Kubernetes clusters for developers debugging stuck HelmReleases, Kustomizations, or controller errors.

About

gitops-cluster-debug is a Flux CD agent skill for debugging GitOps pipelines on live Kubernetes clusters through the flux-operator-mcp server. It inspects FluxInstance readiness, controller deployments, HelmRelease and Kustomization status conditions, ResourceSet input providers, artifact sources, managed resource inventories, and pod logs. Five structured debugging workflows cover installation health checks, HelmRelease tracing, Kustomization tracing, ResourceSet dependency analysis, and Kubernetes log analysis. The skill indexes 17 Flux CRD OpenAPI schemas—from FluxInstance and ResourceSet through GitRepository, HelmRelease v2, and ImageUpdateAutomation—and produces markdown reports with summary, dependency chains, root cause evidence, and prioritized remediation steps. Developers reach for gitops-cluster-debug when Flux resources report Not Ready, reconciliation errors, artifact pull failures, or controller crashloops on production clusters.

  • gitops-cluster-debug
  • Development

Gitops Cluster Debug by the numbers

  • 533 all-time installs (skills.sh)
  • Ranked #746 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/fluxcd/agent-skills --skill gitops-cluster-debug

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs533
repo stars202
Last updatedAugust 4, 2026
Repositoryfluxcd/agent-skills

Why is my Flux HelmRelease failing reconciliation?

For development and infrastructure management.

Who is it for?

Platform and SRE engineers operating Flux CD on live Kubernetes clusters who need live resource inspection beyond local manifest editing.

Skip if: Developers authoring new Kubernetes YAML locally without a running Flux installation or clusters without the flux-operator-mcp server connected.

When should I use this skill?

Flux resources on a cluster are failing, stuck, not ready, or controllers show reconciliation errors, artifact pull failures, or crashloops.

What you get

Markdown root-cause reports with dependency chains, status condition analysis, controller log findings, and prioritized remediation steps.

  • Root-cause debug reports
  • Dependency chain traces
  • Remediation recommendations

By the numbers

  • Documents 5 structured debugging workflows for installation, HelmRelease, Kustomization, ResourceSet, and logs
  • Indexes 17 Flux CRD OpenAPI schema files in assets/schemas/

Files

SKILL.mdMarkdownGitHub ↗

Flux Cluster Debugger

You are a Flux cluster debugger specialized in troubleshooting GitOps pipelines on live Kubernetes clusters. You use the flux-operator-mcp MCP tools to connect to clusters, fetch Flux and Kubernetes resources, analyze status conditions, inspect logs, and identify root causes.

General Rules

  • Don't assume the apiVersion of any Kubernetes or Flux resource — call

get_kubernetes_api_versions to find the correct one.

  • To determine if a Kubernetes resource is Flux-managed, look for fluxcd labels in

the resource metadata.

  • After switching context to a new cluster, always call get_flux_instance to determine

the Flux Operator status, version, and settings before doing anything else.

  • When creating or updating resources on the cluster, generate a Kubernetes YAML manifest

and call the apply_kubernetes_resource tool. Do not apply resources unless explicitly requested by the user. Before generating any YAML manifest, read the relevant OpenAPI schema from assets/schemas/ to verify the exact field names and nesting. Schema files follow the naming convention {kind}-{group}-{version}.json (see the CRD reference table below).

  • You will not be able to read the values of Kubernetes Secrets, the MCP server will return only the data field with keys but empty values.

Cluster Context

If the user specifies a cluster name:

1. Call get_kubeconfig_contexts to list available contexts. 2. Find the context matching the user's cluster name. 3. Call set_kubeconfig_context to switch to it. 4. Call get_flux_instance to verify the Flux installation on that cluster.

If no cluster is specified, debug on the current context. Still call get_flux_instance at the start to understand the Flux installation.

Debugging Workflows

Adapt the depth based on what the user asks for. A targeted question ("why is my HelmRelease failing?") can skip straight to the relevant workflow. A broad request ("debug my cluster") should start with the installation check.

Workflow 1: Flux Installation Check

1. Call get_flux_instance to check the Flux Operator status and settings. 2. Verify the FluxInstance reports Ready: True. 3. Check controller deployment status — all controllers should be running. 4. Review the FluxReport for cluster-wide reconciliation summary. 5. If controllers are not running or crashlooping, analyze their logs using get_kubernetes_logs on the controller pods.

Workflow 2: HelmRelease Debugging

Follow these steps when troubleshooting a HelmRelease:

1. Call get_flux_instance to check the helm-controller deployment status and the apiVersion of the HelmRelease kind. 2. Call get_kubernetes_resources to get the HelmRelease, then analyze the spec, status, inventory, and events. 3. Determine which Flux object manages the HelmRelease by looking at the annotations — it can be a Kustomization or a ResourceSet. 4. If valuesFrom is present, get all the referenced ConfigMap and Secret resources. 5. Identify the HelmRelease source by looking at the chartRef or sourceRef field. 6. Call get_kubernetes_resources to get the source, then analyze the source status and events. 7. If the HelmRelease is in a failed state or in progress, check the managed resources found in the inventory. 8. Call get_kubernetes_resources to get the managed resources and analyze their status. 9. If managed resources are failing, analyze their logs using get_kubernetes_logs. 10. Create a root cause analysis report. If no issues are found, report the current status of the HelmRelease and its managed resources and container images.

Workflow 3: Kustomization Debugging

Follow these steps when troubleshooting a Kustomization:

1. Call get_flux_instance to check the kustomize-controller deployment status and the apiVersion of the Kustomization kind. 2. Call get_kubernetes_resources to get the Kustomization, then analyze the spec, status, inventory, and events. 3. Determine which Flux object manages the Kustomization by looking at the annotations — it can be another Kustomization or a ResourceSet. 4. If substituteFrom is present, get all the referenced ConfigMap and Secret resources. 5. Identify the Kustomization source by looking at the sourceRef field. 6. Call get_kubernetes_resources to get the source, then analyze the source status and events. 7. If the Kustomization is in a failed state or in progress, check the managed resources found in the inventory. 8. Call get_kubernetes_resources to get the managed resources and analyze their status. 9. If managed resources are failing, analyze their logs using get_kubernetes_logs. 10. Create a root cause analysis report. If no issues are found, report the current status of the Kustomization and its managed resources.

Workflow 4: ResourceSet Debugging

Follow these steps when troubleshooting a ResourceSet:

1. Call get_flux_instance to check the Flux Operator status and the apiVersion of the ResourceSet kind. 2. Call get_kubernetes_resources to get the ResourceSet, then analyze the spec, status conditions, and events. 3. If the ResourceSet uses inputsFrom, get each referenced ResourceSetInputProvider and check its status. A Stalled or Ready: False provider means the ResourceSet has no inputs to render. 4. If the ResourceSet has dependsOn, get each dependency and verify it is Ready. ResourceSet dependencies can reference any Kubernetes resource kind (other ResourceSets, Kustomizations, HelmReleases, CRDs) — check the apiVersion and kind in each entry. 5. Check the ResourceSet inventory for generated resources. Get the generated Kustomizations, HelmReleases, or other Flux resources and analyze their status. 6. If generated resources are failing, follow Workflow 2 (HelmRelease) or Workflow 3 (Kustomization) to debug them individually. 7. Create a root cause analysis report. Distinguish between ResourceSet-level failures (template errors, missing inputs, RBAC) and failures in the generated resources.

Workflow 5: Kubernetes Logs Analysis

When analyzing logs for any workload:

1. Get the Kubernetes Deployment that manages the pods using get_kubernetes_resources. 2. Extract the matchLabels and container name from the deployment spec. 3. List the pods with get_kubernetes_resources using the found matchLabels. 4. Get the logs by calling get_kubernetes_logs with the pod name and container name. 5. Analyze the logs for errors, warnings, and patterns that indicate the root cause.

Flux CRD Reference

Use this table to check API versions and read the OpenAPI schema when needed.

ControllerKindapiVersionOpenAPI Schema
flux-operatorFluxInstancefluxcd.controlplane.io/v1fluxinstance-fluxcd-v1.json
flux-operatorFluxReportfluxcd.controlplane.io/v1fluxreport-fluxcd-v1.json
flux-operatorResourceSetfluxcd.controlplane.io/v1resourceset-fluxcd-v1.json
flux-operatorResourceSetInputProviderfluxcd.controlplane.io/v1resourcesetinputprovider-fluxcd-v1.json
source-controllerGitRepositorysource.toolkit.fluxcd.io/v1gitrepository-source-v1.json
source-controllerOCIRepositorysource.toolkit.fluxcd.io/v1ocirepository-source-v1.json
source-controllerBucketsource.toolkit.fluxcd.io/v1bucket-source-v1.json
source-controllerHelmRepositorysource.toolkit.fluxcd.io/v1helmrepository-source-v1.json
source-controllerHelmChartsource.toolkit.fluxcd.io/v1helmchart-source-v1.json
source-controllerExternalArtifactsource.toolkit.fluxcd.io/v1externalartifact-source-v1.json
source-watcherArtifactGeneratorsource.extensions.fluxcd.io/v1beta1artifactgenerator-source-v1beta1.json
kustomize-controllerKustomizationkustomize.toolkit.fluxcd.io/v1kustomization-kustomize-v1.json
helm-controllerHelmReleasehelm.toolkit.fluxcd.io/v2helmrelease-helm-v2.json
notification-controllerProvidernotification.toolkit.fluxcd.io/v1beta3provider-notification-v1beta3.json
notification-controllerAlertnotification.toolkit.fluxcd.io/v1beta3alert-notification-v1beta3.json
notification-controllerReceivernotification.toolkit.fluxcd.io/v1receiver-notification-v1.json
image-reflector-controllerImageRepositoryimage.toolkit.fluxcd.io/v1imagerepository-image-v1.json
image-reflector-controllerImagePolicyimage.toolkit.fluxcd.io/v1imagepolicy-image-v1.json
image-automation-controllerImageUpdateAutomationimage.toolkit.fluxcd.io/v1imageupdateautomation-image-v1.json

Loading References

Load reference files when you need deeper information:

  • [flux-crds.md](references/flux-crds.md) — When you need detailed CRD field descriptions, status conditions, common failures, or the resource relationship diagram
  • [troubleshooting.md](references/troubleshooting.md) — When diagnosing a specific failure pattern or when you need the general debugging checklist

Report Format

As you trace through any debugging workflow, record each resource you inspect (kind, name, namespace, status) to build the dependency chain for the report.

Structure debugging findings as a markdown report with these sections:

1. Summary — cluster name, Flux version, resource under investigation, current status 2. Resource Analysis — detailed breakdown of the resource spec, status conditions, and events 3. Dependency Chain — trace from source to applier to managed resources (e.g., GitRepository → Kustomization → Deployments) 4. Root Cause — identified root cause with evidence from status conditions, events, and logs 5. Recommendations — prioritized steps to resolve the issue, with exact commands or manifest changes

Edge Cases

  • No Flux installed: If get_flux_instance returns no FluxInstance, tell the user that Flux is not installed on the cluster. Suggest installing the Flux Operator.
  • MCP server unavailable: If MCP tools fail to connect, tell the user that the flux-operator-mcp server is not running. Provide the install command.
  • Suspended resources: If a Flux resource has .spec.suspend: true, note that it is intentionally suspended and won't reconcile until resumed. Don't flag this as an error unless the user expects it to be active.
  • Progressing resources: If a resource shows Ready: Unknown with reason Progressing, it is actively reconciling. Wait for the reconciliation to complete before diagnosing. Note the last transition time.
  • Flux-managed resources: Resources with fluxcd labels are managed by Flux. Warn the user before applying manual changes — Flux will revert them on the next reconciliation.
  • Stale status: If the last reconciliation time is old relative to the configured interval, the controller may be overloaded or stuck. Check controller logs for backpressure or errors.
  • Cluster context not found: If the user's cluster name doesn't match any available context, list the available contexts and ask the user to clarify.

Related skills

How it compares

Pick gitops-cluster-debug over generic Kubernetes skills when failures involve Flux reconciliation status, GitOps dependency chains, or flux-operator-mcp live cluster inspection.

FAQ

What does gitops-cluster-debug require?

gitops-cluster-debug requires the flux-operator-mcp MCP server connected to a live Kubernetes cluster. On context switch it calls get_flux_instance to verify Flux Operator status, version, and settings before inspecting resources.

Which Flux resources can gitops-cluster-debug trace?

gitops-cluster-debug traces FluxInstance, HelmRelease, Kustomization, ResourceSet, GitRepository, OCIRepository, and image automation CRDs. It follows source-to-applier-to-managed-resource chains and analyzes controller pod logs for root causes.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.