> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/integrations/deployment-integrations/argo-cd-deployment-pipeline.md).

# Argo CD deployment pipeline

Report Argo CD syncs to ilert through the notifications controller, so alerts arrive with the rollout that most likely caused them.

Argo CD reports through its **notifications controller**: you register ilert as a webhook service, define a template for the payload, define triggers that decide when to send it, and then subscribe individual applications with an annotation.

Because the trigger fires on the sync's *outcome*, the events that reach ilert say a rollout finished — not merely that a commit landed. That is the strongest signal a deployment integration can give an alert.

## Create the pipeline

Follow [Create a deployment pipeline](/integrations/deployment-integrations.md#create-a-deployment-pipeline) and choose type **Argo CD**. An Argo CD pipeline has no branch or event filters — what is sent is decided by the triggers and subscriptions below.

Copy the **URL** from the pipeline's detail view; it goes into the configmap as `YOUR_PIPELINE_URL`.

## Configure the notifications controller

Add the ilert service, templates, and triggers to the `argocd-notifications-cm` configmap. If you already have one, merge these keys into its existing `data` block rather than replacing the file:

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.webhook.ilert: |
    url: YOUR_PIPELINE_URL
    headers:
      - name: "Content-Type"
        value: "application/json"

  template.ilert-app-sync-template: |
    webhook:
      ilert:
        method: POST
        body: |
          {
            "app": {{ toJson .app }},
            "commit": {{ if .app.status.sync.revision }}{{ call .repo.GetCommitMetadata .app.status.sync.revision | toJson }}{{ else }}null{{ end }},
            "repositoryName": "{{ call .repo.FullNameByRepoURL .app.spec.source.repoURL }}"
          }

  template.ilert-app-deleted-template: |
    webhook:
      ilert:
        method: POST
        body: |
          {
            "app": {{ toJson .app }},
            "repositoryName": "{{ call .repo.FullNameByRepoURL .app.spec.source.repoURL }}"
          }

  trigger.on-deployed: |
    - when: app.status.operationState.phase in ['Error', 'Failed', 'Succeeded']
      send: [ilert-app-sync-template]

  trigger.on-app-deleted: |
    - when: app.metadata.deletionTimestamp != nil
      send: [ilert-app-deleted-template]
```

Two details are easy to misread:

* `service.webhook.ilert` names the service `ilert`, which is the key the templates address under `webhook:`. Rename one and you must rename all of them.
* `on-deployed` fires on `Error` and `Failed` as well as `Succeeded`. That is deliberate — a rollout that failed halfway is exactly the change you want on the alert.

## Subscribe an application

Nothing is sent until an application opts in. Annotate each one you want reported:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    notifications.argoproj.io/subscribe.on-deployed.ilert: ""
    notifications.argoproj.io/subscribe.on-app-deleted.ilert: ""
```

The annotation reads `subscribe.<trigger>.<service>`, so both halves have to match the names you used in the configmap.

## Confirm it arrived

Sync an application, then check that a row appears under **Alerting** → **Deployment events** in ilert. If nothing shows up, the notifications controller's own logs report the outcome of the webhook call — a subscription that never fired and a POST that was rejected look completely different there, and ilert's `202` response tells you nothing either way.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ilert.com/integrations/deployment-integrations/argo-cd-deployment-pipeline.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.