Send Flux Reconciliation Alerts to Slack (2026)

Flux, the GitOps tool, can’t just magically send alerts to Slack when something goes sideways. You need to wire it up.

Here’s Flux in action, making a change and then reporting its success.

apiVersion: v1
kind: Namespace
metadata:
  name: my-app
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: my-app-kustomization
  namespace: flux-system
spec:
  interval: 10m
  path: ./clusters/my-cluster/apps/my-app
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-system
  targetNamespace: my-app
  validation: client
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: my-app-deployment
      namespace: my-app

This Kustomization object tells Flux to periodically check a specific path in a Git repository (./clusters/my-cluster/apps/my-app). If it finds changes, it applies them to the my-app namespace. Flux also defines a health check for a Deployment named my-app-deployment to ensure the application is running as expected.

To get alerts into Slack, you’ll use a combination of Flux’s built-in notification capabilities and a dedicated controller. Flux has a NotificationController which acts as a central hub for outgoing events. This controller can be configured to send notifications to various providers, including Slack.

The core components are:

Flux NotificationController: This is the agent that watches for events from other Flux controllers (like Kustomization, HelmRelease, etc.) and routes them to configured providers.
Alert Custom Resource: This CRD defines what events to send and where to send them. You’ll specify the provider (Slack), the channel, and the conditions under which alerts should be sent (e.g., on Error, Info, Warn).
Provider Custom Resource: This CRD defines the credentials and configuration for each notification provider. For Slack, this means providing the webhook URL.

Let’s set up a Slack provider and an alert.

First, the Provider:

apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: slack
  namespace: flux-system # Must be in the same namespace as the NotificationController
spec:
  type: slack
  secretRef:
    name: slack-url # This secret will hold your Slack webhook URL

Next, the Alert object:

apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: flux-alerts
  namespace: flux-system # Can be in any namespace, but often placed with NotificationController
spec:
  eventSeverity: error # Send alerts for errors
  eventSources:
    - kind: Kustomization
      name: "*" # Send alerts for all Kustomizations
    - kind: HelmRelease
      name: "*" # Send alerts for all HelmReleases
  providerRef:
    name: slack # Reference the Slack provider we defined above
  # You can also specify a specific channel here if you don't want to rely on the webhook's default
  # channel: "#flux-notifications"

Finally, you need to create a Kubernetes Secret named slack-url in the flux-system namespace. This secret will contain your Slack incoming webhook URL.

apiVersion: v1
kind: Secret
metadata:
  name: slack-url
  namespace: flux-system
type: Opaque
stringData:
  # Replace with your actual Slack incoming webhook URL
  # This URL is sensitive, ensure your cluster's RBAC is configured correctly
  # to restrict access to this secret.
  url: "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"

When a Kustomization fails to reconcile (e.g., due to invalid YAML in your Git repo, or a Kubernetes resource failing to deploy), the Kustomization controller will emit an event. The NotificationController will pick this up, see that there’s an Alert configured to send error events from Kustomization sources to the slack provider, and then use the slack-url secret to post a message to Slack.

The most surprising thing about Flux notifications is that they are not a separate service you install; they are an integrated part of the core Flux controllers, managed via standard Kubernetes Custom Resource Definitions. This means you can manage your notification routing and provider configurations just like any other Kubernetes workload, using GitOps.

The Provider resource defines the how (type of service, credentials), and the Alert resource defines the what (event types, sources, destination channel). This separation allows for flexible routing of different event types to different destinations or channels without reconfiguring the underlying provider credentials. For example, you could have one Alert for error events going to a #devops-alerts channel and another Alert for info events going to a #gitops-updates channel, both using the same Slack Provider.

The eventSeverity field on the Alert resource is crucial. It accepts info, warn, and error. By default, if not specified, it will only send error level events. You can also specify multiple severities like eventSeverity: ["error", "warn"]. This allows you to fine-tune the noise level you receive in your Slack channels.

When Flux reconciles a Kustomization and it succeeds, no event is typically sent unless you explicitly configure an Alert with eventSeverity: "info". This is a deliberate design choice to avoid flooding channels with routine success messages. You usually want to be alerted when things break, not when they work as expected.

The next step is to explore how to create custom notification templates for Slack, allowing you to format the alerts with more context or even include links to your Git repository or Kubernetes dashboard.