Argo CD change integration

Plan requirement: This feature requires an On-call Standard or higher subscription. Learn more

Argo CD pushes changes through its built-in Notifications (argocd-notifications-controller). This integration provides an argocd-notifications-cm configuration with one webhook service, one request body template, and one trigger. Each sync operation of an Argo CD Application becomes one Flashduty change. Flashduty records it as Processing when the sync starts and updates it to Done, Failed, or Canceled when it ends. Automated syncs, manual syncs from the UI or CLI, and rollbacks are all sync operations, and Flashduty records them all. For sync-failed and health-degraded alerts, use the Argo CD alert integration; both integrations can be configured side by side.

Configure Argo CD

The steps below need Kubernetes permission to edit ConfigMaps in the Argo CD namespace (argocd by default) and to edit annotations on Applications or AppProjects. The Argo CD cluster must be able to reach the domain of the push URL.

Add the webhook service, template, and trigger

Save the following as flashduty-change.yaml and replace url with the push URL copied above (including ?integration_key=...):

data:
  service.webhook.flashduty-change: |
    url: {integration_url}
    headers:
    - name: Content-Type
      value: application/json

  template.flashduty-change: |
    webhook:
      flashduty-change:
        method: POST
        body: |
          {
            "app_uid": {{ .app.metadata.uid | toJson }},
            "app_name": {{ .app.metadata.name | toJson }},
            "app_namespace": {{ .app.metadata.namespace | toJson }},
            "project": {{ .app.spec.project | toJson }},
            "destination": {{ dig "spec" "destination" "name" (dig "spec" "destination" "server" "" .app) .app | toJson }},
            "destination_namespace": {{ dig "spec" "destination" "namespace" "" .app | toJson }},
            "argocd_url": {{ .context.argocdUrl | toJson }},
            "phase": {{ dig "status" "operationState" "phase" "" .app | toJson }},
            "message": {{ dig "status" "operationState" "message" "" .app | toJson }},
            "started_at": {{ dig "status" "operationState" "startedAt" "" .app | toJson }},
            "finished_at": {{ dig "status" "operationState" "finishedAt" "" .app | toJson }},
            "revision": {{ dig "status" "operationState" "syncResult" "revision" (dig "status" "operationState" "operation" "sync" "revision" "" .app) .app | toJson }},
            "initiated_by": {{ dig "status" "operationState" "operation" "initiatedBy" "username" "" .app | toJson }},
            "automated": {{ dig "status" "operationState" "operation" "initiatedBy" "automated" false .app | toJson }},
            "dry_run": {{ dig "status" "operationState" "operation" "sync" "dryRun" false .app | toJson }}
          }

  trigger.on-flashduty-change: |
    - when: app.status.operationState != nil and app.status.operationState.phase in ['Running']
      oncePer: app.status.operationState?.startedAt
      send: [flashduty-change]
    - when: app.status.operationState != nil and app.status.operationState.phase in ['Succeeded', 'Failed', 'Error']
      oncePer: app.status.operationState?.startedAt
      send: [flashduty-change]

Merge it into the existing argocd-notifications-cm (--type merge only adds or updates the keys above and leaves the rest of the configuration alone):

kubectl patch configmap argocd-notifications-cm -n argocd --type merge --patch-file flashduty-change.yaml

If Argo CD is installed with the Helm chart, put service.webhook.flashduty-change under notifications.notifiers, the template under notifications.templates, and the trigger under notifications.triggers; otherwise the next upgrade overwrites manual edits.Notes:

Every value in the template is escaped with toJson, so quotes and line breaks in sync messages cannot break the JSON. Do not remove it. Do not rename fields; app_uid, phase, and started_at are required
Optional fields are read with dig, so the template renders even when the application has never synced or the sync has no result yet
The two trigger conditions cover the start and the end of a sync. oncePer is the sync operation’s start time. It makes Argo CD send each sync’s start and end once, even when it misses the state between two consecutive syncs. Don’t remove it
The service name flashduty-change differs from flashduty used by the alert integration, so the two integrations’ push URLs do not interfere
argocd_url comes from context.argocdUrl in argocd-notifications-cm and is used to build the change link. Without it, changes have no link but are still recorded

Subscribe to notifications

A trigger sends only after it is subscribed. Choose one scope:

One application: add an annotation to the Application

kubectl patch application <app name> -n argocd --type merge \
  -p '{"metadata":{"annotations":{"notifications.argoproj.io/subscribe.on-flashduty-change.flashduty-change":""}}}'

All applications in a project: add the same annotation notifications.argoproj.io/subscribe.on-flashduty-change.flashduty-change: "" to the AppProject’s metadata.annotations
All applications: add an entry to subscriptions in argocd-notifications-cm. If subscriptions already exists (for example the entry added by the alert integration), append to the existing list instead of overwriting it with the merge command above
subscriptions: | - recipients: - flashduty-change triggers: - on-flashduty-change

When the subscription takes effect, each application that synced before sends its latest sync result at once. Flashduty records it as one change with that sync’s original start and end times.

Test connectivity

Argo CD has no button for sending a test message. From the argocd-notifications-controller Pod, use argocd admin notifications template notify to send one notification based on the application’s current state:

kubectl exec -n argocd deploy/argocd-notifications-controller -- \
  /usr/local/bin/argocd admin notifications template notify flashduty-change <app name> --recipient flashduty-change

The command prints debug logs of the request and response, including the full push URL with its integration_key, so do not paste the output anywhere public. A 200 OK status on the Received response: line means Flashduty accepted the request. For an application that synced before, this notification carries its latest sync result. It merges into that sync’s existing record and adds no change. For an application that never synced, Flashduty ignores it.

Verify sync records

Sync a subscribed application (click Sync in the UI, or run argocd app sync <app name>). Confirm that a Processing change appears in the Flashduty change list and that it updates to Done or Failed when the sync ends.

How changes are merged

One change is one sync operation of one application:

The start, failed retries, and final result of one sync update the same change
Two syncs of one application are two changes, even for the same revision
Same-named applications in different Argo CD instances, and applications deleted and recreated, are never merged

Changes to the application name, project, revision, or sync message do not create a new change.

Status mapping

Argo CD sync phase (`phase`)	Flashduty change status
`Running`, `Terminating`	Processing
`Succeeded`	Done
`Failed`, `Error`	Failed
`Failed` with the message `Operation terminated` (Terminate in the UI, or `argocd app terminate-op`)	Canceled

Done, Failed, and Canceled are end states; Flashduty records the change’s end time. An operation that Argo CD terminates because of the sync timeout (the message contains triggered by controller sync timeout) becomes Failed. Sync phases are case-sensitive, and Flashduty rejects other values. The following deliveries return success without creating a change: an application with no sync operation yet (empty phase), and dry-run syncs. The recorded time is started_at when a sync starts and finished_at when it ends. While Argo CD retries a failed sync automatically, the phase stays Running, so the change is not marked Failed early.

Change content

Title: <app name>: sync <revision> to <destination namespace>. A Git commit shows its first 7 characters; other values, such as a Helm chart version, are shown as is. The revision or destination namespace part is omitted when empty
Link: <argocdUrl>/applications/<app name>, only when context.argocdUrl is configured

Use labels for routing and for filtering the change list:

Label	Description
`application`	Application name
`app_uid`	The application’s `metadata.uid`
`app_namespace`	Namespace of the Application object
`project`	Argo CD project of the application
`destination`	Destination cluster name, or the cluster address when no name is set
`destination_namespace`	Destination namespace
`revision`	Synced revision (Git commit or chart version)
`actor`	User who started the sync; `automated` for automated syncs
`phase`	Latest sync phase
`message`	Latest sync message, such as the failure reason, truncated beyond 1024 bytes

Empty fields are not written as labels.

FAQ

Why are no changes received?

Check the argocd-notifications-controller logs (kubectl logs -n argocd deploy/argocd-notifications-controller) and confirm that the application has the notifications.argoproj.io/subscribe.on-flashduty-change.flashduty-change annotation, or that subscriptions includes on-flashduty-change
If the logs show template 'flashduty-change' is not supported or trigger 'on-flashduty-change' is not configured, confirm the configuration is in argocd-notifications-cm; for Helm installs, check the corresponding values

Only the end of a sync arrived, not the start?

When a sync finishes within a few seconds, Argo CD may not observe the Running phase and sends only the end notification. Flashduty records the change directly in its end state.

Is the same notification recorded twice if it is sent again?

No. Flashduty records an event with the same phase and the same time only once.

The logs show failed with error code 400?

Confirm the template matches this page and every value goes through toJson. The response names the missing or unsupported field, such as app_uid is missing, started_at is missing, or unsupported phase.

For related configuration, see the Argo CD documentation on Webhook, Triggers, Templates, and Subscriptions.

Quick Start

Product Comparison

Channels

Incident Management

Post-Mortem

Status Page

Analytics

Integration Settings

Configuration

Advanced

Integrations

Best Practices

Argo CD change integration

In Flashduty On-call

Configure Argo CD

How changes are merged

Status mapping

Change content

FAQ