observe-flux

Diagnose Flux-managed Kubernetes resources by tracing ownership to Kustomizations or HelmReleases.

14|Updated Jan 17, 2026
One-click install
npx skills add https://github.com/confighub/cub-scout --skill observe-flux
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: observe-flux
Source: https://github.com/confighub/cub-scout/tree/main/skills/observe-flux
Command: npx skills add https://github.com/confighub/cub-scout --skill observe-flux

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It helps you determine whether a Kubernetes resource is managed by Flux and precisely explain where its values came from, why it’s unhealthy or drifting, and which Flux controller and source artifact are responsible.

Core Features & Use Cases

  • Flux ownership detection: Identifies Flux-managed resources using controller-specific label families for Kustomizations and HelmReleases.
  • Managed-field attribution: Explains which controller wrote observed fields by matching Flux’s exact metadata.managedFields.manager strings (kustomize-controller, helm-controller, source-controller).
  • Trace back to Flux source artifacts: Walks the chain from a workload to its owning Kustomization/HelmRelease, then to the underlying source (GitRepository, OCIRepository, HelmRepository, Bucket, HelmChart) via spec.sourceRef and source revision evidence.

Quick Start

Ask the skill to explain why a deployment is unhealthy and whether Flux is the real owner, including which Kustomization/HelmRelease and which source artifact produced it.

Frequently Asked Questions about observe-flux

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

FAQPage Schema
How do I find which Flux Kustomization or HelmRelease owns a Kubernetes resource?

Flux ownership is detected by inspecting Kubernetes resources for controller-specific label families and matching exact `metadata.managedFields.manager` strings to kustomize-controller, helm-controller, or source-controller.

How does Flux trace a workload back to its source artifact?

Flux traces workloads back to source artifacts by walking the chain from the owning Kustomization or HelmRelease to the underlying GitRepository, OCIRepository, or HelmRepository via `spec.sourceRef` and source revision evidence.

Why is my Flux-managed Kubernetes resource unhealthy or drifting?

Flux-managed resources drift or become unhealthy due to reconcile failures or configuration mismatches, diagnosed through read-only inspection of Flux controller traces and source revision evidence.

Can I diagnose Kubernetes resources managed by Flux without modifying them?

Yes, Flux-managed Kubernetes resources are diagnosed using read-only inspection of objects, applying Flux-aware detection and controller trace logic to explain ownership and reconcile outcomes without applying changes.

What is the best way to identify which Flux controller wrote specific fields on a Kubernetes object?

The best way to attribute specific fields on a Kubernetes object is by matching `metadata.managedFields.manager` strings to kustomize-controller, helm-controller, or source-controller to pinpoint the writing controller accurately.

Does Flux ownership detection work with both HelmRelease and Kustomization controllers?

Yes, Flux ownership detection applies to both HelmRelease and Kustomization controllers by identifying resources through controller-specific label families and matching their respective managedFields manager strings.