> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Flux CD change integration
> Sync every revision that Kustomizations and HelmReleases apply to Flashduty On-call through the Flux notification-controller generic Provider, as change events you can correlate with alerts and incidents.
**Plan requirement**: This feature requires an On-call Standard or higher subscription. [Learn more](https://flashcat.cloud/flashduty/price/)
Flux's kustomize-controller and helm-controller emit events when they apply a new revision, and the notification-controller `generic` Provider can push those events out as JSON. This integration receives them: each Git or OCI revision that a Kustomization applies, and each chart version that a HelmRelease installs or upgrades, becomes one Flashduty change.
* **Kustomization**: recorded as Processing when the revision starts to apply, updated to Done when the reconciliation succeeds, and to Failed when it fails
* **HelmRelease**: helm-controller only sends an event when an action ends, so the change is recorded directly as Done or Failed
Events of other kinds (GitRepository, HelmChart, ImageUpdateAutomation, and so on) and events without a revision (for example an invalid Kustomization spec or a missing source) are not changes and are not recorded. A Flux Provider can also push the same events as alerts. See [Flux CD alert integration](/en/on-call/integration/alert-integration/alert-sources/fluxcd); you can use both integrations at the same time.
## In Flashduty On-call
***
1. In the Flashduty console, go to **Integration Center → Change Events**
2. Select **Flux CD** and enter an integration name
3. To assign changes to specific channels, add rules under the integration's **Routes** that match labels such as `namespace`, `name`, or `cluster`
4. Click **Save** and copy the generated **Push URL**
## Configure Flux
***
The steps below need Kubernetes permission to create Providers, Alerts, and Secrets in the `flux-system` namespace (or the namespace where you keep notification config). The notification-controller must be able to reach the domain of the push URL.
The push URL contains the `integration_key`, so do not write it into the Provider. Store it under the `address` key of a Secret:
```bash theme={null}
kubectl -n flux-system create secret generic flashduty-change \
--from-literal=address=''
```
Save the following as `flashduty-change.yaml` and run `kubectl apply -f flashduty-change.yaml`:
```yaml theme={null}
apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Provider
metadata:
name: flashduty-change
namespace: flux-system
spec:
type: generic
secretRef:
name: flashduty-change
---
apiVersion: notification.toolkit.fluxcd.io/v1beta3
kind: Alert
metadata:
name: flashduty-change
namespace: flux-system
spec:
providerRef:
name: flashduty-change
eventSeverity: info
eventSources:
- kind: Kustomization
name: '*'
namespace: flux-system
- kind: HelmRelease
name: '*'
namespace: flux-system
eventMetadata:
cluster: prod-eu
```
* `eventSeverity` must be `info`. Flux's `info` level includes `error` events; with `error` you would miss the start and success events, and changes could never finish
* List `eventSources` for the scope you need: `name: '*'` matches every object of that kind in the namespace, and objects in other namespaces need their own entry with `namespace`
* The keys and values in `eventMetadata` are written to the change as labels. Use them for `cluster`, `env`, and other information the Flux event does not carry, to tell clusters apart and to match in routes. Use the same values in every Alert of one cluster
* The Provider type can also be `generic-hmac`, which adds an `X-Signature` header; Flashduty does not verify that header
Flux has no way to send a test message. Change the source of a Kustomization that the Alert selects (for example, commit a change to its Git repository) and confirm the change appears in the Flashduty change list: once the Kustomization has applied the new revision, the change is updated to Done. Use these commands to check that the Provider and Alert are ready and to see why a push failed:
```bash theme={null}
kubectl -n flux-system get provider,alert
kubectl -n flux-system describe alert flashduty-change
```
## What one change is
***
One change is one revision applied by one Flux object. Its change key (change\_key) is `