Skip to content

Notifications Overview

Argo CD Notifications continuously monitors Argo CD applications and provides a flexible way to notify users about important changes in the application state. Using a flexible mechanism of triggers and templates you can configure when the notification should be sent as well as notification content. Argo CD Notifications includes the catalog of useful triggers and templates. So you can just use them instead of reinventing new ones.

Getting Started

  • Install Triggers and Templates from the catalog

    kubectl apply -n argocd -f
  • Add Email username and password token to argocd-notifications-secret secret

    kubectl apply -n argocd -f - << EOF
    apiVersion: v1
    kind: Secret
      name: argocd-notifications-secret
      email-username: $EMAIL_USER
      email-password: $PASSWORD
    type: Opaque
  • Register Email notification service

    kubectl patch cm argocd-notifications-cm -n argocd --type merge -p '{"data": {"": "{ username: $email-username, password: $email-password, host:, port: 465, from: $email-username }" }}'
  • Subscribe to notifications by adding the annotation to the Argo CD application or project:

    kubectl patch app <my-app> -n argocd -p '{"metadata": {"annotations": {"":"<my-channel>"}}}' --type merge

Try syncing an application to get notified when the sync is completed.

Namespace based configuration

A common installation method for Argo CD Notifications is to install it in a dedicated namespace to manage a whole cluster. In this case, the administrator is the only person who can configure notifications in that namespace generally. However, in some cases, it is required to allow end-users to configure notifications for their Argo CD applications. For example, the end-user can configure notifications for their Argo CD application in the namespace where they have access to and their Argo CD application is running in.

This feature is based on applications in any namespace. See applications in any namespace page for more information.

In order to enable this feature, the Argo CD administrator must reconfigure the argocd-notification-controller workloads to add --application-namespaces and --self-service-notification-enabled parameters to the container's startup command. --application-namespaces controls the list of namespaces that Argo CD applications are in. --self-service-notification-enabled turns on this feature.

The startup parameters for both can also be conveniently set up and kept in sync by specifying the application.namespaces and notificationscontroller.selfservice.enabled in the argocd-cmd-params-cm ConfigMap instead of changing the manifests for the respective workloads. For example:

apiVersion: v1
kind: ConfigMap
  name: argocd-cmd-params-cm
  application.namespaces: app-team-one, app-team-two
  notificationscontroller.selfservice.enabled: "true"

To use this feature, you can deploy configmap named argocd-notifications-cm and possibly a secret argocd-notifications-secret in the namespace where the Argo CD application lives.

When it is configured this way the controller will send notifications using both the controller level configuration (the configmap located in the same namespaces as the controller) as well as the configuration located in the same namespace where the Argo CD application is at.

Example: Application team wants to receive notifications using PagerDutyV2, when the controller level configuration is only supporting Slack.

The following two resources are deployed in the namespace where the Argo CD application lives.

apiVersion: v1
kind: ConfigMap
  name: argocd-notifications-cm
  service.pagerdutyv2: |
      my-service: $pagerduty-key-my-service
apiVersion: v1
kind: Secret
  name: argo-cd-notification-secret
type: Opaque
  pagerduty-key-my-service: <pd-integration-key>

When an Argo CD application has the following subscriptions, user receives application sync failure message from pager duty.

kind: Application
  annotations: "<serviceID for Pagerduty>"


When the same notification service and trigger are defined in controller level configuration and application level configuration, both notifications will be sent according to its own configuration.

Defining and using secrets within notification templates function is not available when flag --self-service-notification-enable is on.