Monitoring ArgoCD with OpenTelemetry means collecting its Prometheus-format metrics and controller logs through the OpenTelemetry Collector and OTLP, so GitOps sync health sits in the same observability pipeline as everything else..
Monitoring ArgoCD with OpenTelemetry means collecting its Prometheus-format metrics and controller logs through the OpenTelemetry Collector and OTLP, so GitOps sync health sits in the same observability pipeline as everything else.
ArgoCD is the control loop for GitOps delivery, so the signals are about whether the cluster is converging on what Git declares: application sync status (Synced vs OutOfSync), health status (Healthy, Degraded, Progressing), sync operation success and duration, and the performance of the repo-server and application controller that do the work. An application stuck OutOfSync or Degraded is a delivery incident, not just a dashboard colour.
The most actionable view is sync and health status per application over time, because a repeated failure to sync, or a drift that keeps reappearing, tells you delivery is broken in a way a one-off glance never would.
ArgoCD exposes Prometheus-format metrics from its application controller, repo-server and API server. Scrape them with the Collector's prometheus receiver and collect the controller logs with the filelog receiver, then export over OTLP so ArgoCD's delivery health lives in the same pipeline as the workloads it deploys.
The setup detail is exposing the metrics ports for each ArgoCD component and pointing the prometheus receiver at all of them; the application controller carries the sync and health metrics, while repo-server metrics reveal the manifest-generation latency that often explains a slow sync.
The signals that explain most ArgoCD incidents:
| Signal | Source | What it tells you / watch for |
|---|---|---|
argocd_app_info | application controller | Carries sync_status and health_status as labels; the source of truth for which apps are OutOfSync or Degraded. |
argocd_app_sync_total | application controller | Sync operations by result; a rising failed count means syncs are not completing. |
argocd_app_reconcile (histogram) | application controller | Reconciliation duration; a climbing tail means the controller is struggling to keep up. |
argocd_git_request_duration | repo-server | Manifest generation and Git fetch latency; slow repo-server work makes syncs slow. |
controller work queue depth | application controller | A growing queue means reconciliation is falling behind across applications. |
An ArgoCD dashboard should show delivery health at a glance. Row one: count of applications by sync status (OutOfSync is the alarm) and by health status (Degraded and stuck-Progressing). Row two: sync failures over time and reconciliation duration. Row three: repo-server request latency and controller queue depth, the two signals that explain a slow or backed-up delivery pipeline.
# applications not in sync
count(argocd_app_info{sync_status="OutOfSync"}) by (name)
# degraded applications
count(argocd_app_info{health_status="Degraded"}) by (name)
# sync failure rate
rate(argocd_app_sync_total{phase="Failed"}[15m]) by (name)An application will not converge to the Git state and stays OutOfSync. Check the sync operation result and the app's conditions: the cause is usually a manifest that fails to apply, a missing dependency, or a resource the controller cannot prune. This is a real delivery failure, not noise.
Health status flips to Degraded because the deployed workload itself is unhealthy, for example pods failing readiness. ArgoCD reports the delivery succeeded but the result is unhealthy; correlate with the workload's own telemetry to find why.
Syncs take longer and longer, and repo-server request duration is high, because manifest generation or Git fetches are slow (large repos, heavy templating). Scale or tune the repo-server rather than assuming the cluster is the bottleneck.
Starting thresholds to tune:
| Condition | Signal | Meaning |
|---|---|---|
| app OutOfSync for > 15m | sync | Delivery is not converging. |
| app Degraded for > 10m | health | Deployed workload is unhealthy. |
| sync failure rate rising | delivery | Syncs are failing repeatedly. |
| reconcile p95 climbing | controller | Controller falling behind. |
Ops Singularity's TelemetryOps ingests ArgoCD metrics over OpenTelemetry, and Sentinel AI can act on a failing sync or degraded application through a governed, reversible Action Ticket. Explore TelemetryOps.
Yes. ArgoCD exposes Prometheus-format metrics from its controllers and API server, which the OpenTelemetry Collector can scrape with its prometheus receiver and export over OTLP.
Application sync and health status, sync failures and durations, and repo-server and controller performance, so you can catch broken GitOps delivery early.
Bring a real incident. We will show you Sentinel investigate, act and verify end to end, with every action reversible and audited.