Monitoring Argo CD with Prometheus and Grafana: what you get and how it connects
Argo CD exposes Prometheus metrics from its four components, so you can detect drift, failed syncs and lost cluster connections before application teams report them. The application controller serves metrics on argocd-metrics port 8082, the API server on argocd-server-metrics port 8083, the repo-server on argocd-repo-server port 8084, and the commit server on argocd-commit-server port 8087. Prometheus pulls these endpoints over HTTP through service discovery or static configuration, stores the samples in its local time series database, and evaluates alert rules against them. Grafana reads from Prometheus to draw dashboards, and Alertmanager receives the firing alerts from Prometheus and routes them to your on-call tools. Each piece is a separate component with its own failure modes, so the design decision is where each one runs and who owns it.
Argo CD, Prometheus, Grafana and Alertmanager are all open source under the Apache License 2.0 (Apache-2.0), and Grafana's licensing page notes that Grafana itself moved to AGPLv3 in 2021, so confirm the license that applies to each component you deploy. None of these projects charges for the software. Your costs come from the infrastructure that runs the scraping, storage and dashboards, from the storage that holds metric history, and from the people who install, upgrade, secure and tune the stack. Prometheus local storage is not clustered or replicated, so a single Prometheus server is a single point of failure for your alerts. Before you start, confirm the retention period you need, whether you need a second Prometheus or a remote write target for long-term storage, and whether you need Grafana in high availability with MySQL or PostgreSQL behind it.
What you need in place before scraping Argo CD
Four components have to be settled before a single scrape target is written: the Argo CD version you run, the Prometheus and Grafana platform that reads it, the network route between them, and the RBAC that lets the monitoring stack see the Argo CD namespace. Each one changes which metrics you can rely on and how much work the setup takes.
Argo CD version line
Target a supported minor line before you write scrape rules, because metric names and labels can change between releases. The release process supplies patch releases only for the three most recent minor versions. As of October 12, 2026, the patch releases on the GitHub releases page were v3.5.5, v3.4.11 and v3.3.16, with v3.6.0 in release candidate. Confirm the exact metric names for your version against the metrics guide before you build alert rules.
Prometheus with discovery support
Decide how Prometheus finds targets before you add Argo CD. A running Prometheus with Kubernetes service discovery works with static scrape jobs, while the Prometheus Operator needs a ServiceMonitor or PodMonitor resource and a selector that matches the Argo CD services. Check which operator version and CRD set your cluster runs, since the field names for scrape configuration differ across versions. Confirm exact scrape configuration against that version.
Prometheus storage and retention
Plan where Prometheus keeps its data before you add metrics. Local storage holds two-hour blocks with a default retention of 15 days, and it is not clustered or replicated, so a single instance is a single point of failure for your dashboards and alert history. Decide whether you need remote write to long-term storage, and size the volume for the number of series your Argo CD metrics produce.
Grafana version and database
Choose a Grafana major line and a backing database before you import the dashboard. Grafana's configuration database defaults to SQLite, which the installation docs say does not scale for production. For production and high availability, use MySQL 8.0 or later or PostgreSQL 12 or later. Grafana 13.2.4, 13.1.8 and 13.0.11 were the patch releases published on October 13, 2026, so pick a supported line and plan upgrades.
Network paths to metrics services
Confirm that Prometheus can reach the four metrics endpoints in the Argo CD namespace. The application controller listens on port 8082, the API server on 8083, the repo-server on 8084 and the commit server on 8087. If you enforce network policies, allow ingress from the Prometheus namespace to each of these ports, and check that TLS and any service mesh sidecars do not block plain HTTP scrapes.
Namespace and RBAC access
Grant the Prometheus service account read access to the Argo CD services and endpoints in the namespace where Argo CD runs, and nothing broader. Scraping needs only read permissions on services, endpoints and pods, so review any cluster-wide role that a template adds. Keep the Argo CD admin user disabled and do not use it for monitoring credentials, since the monitoring path should never depend on an interactive login.
Configure the scrape, alerts and dashboard in order
This sequence moves from confirming that Argo CD's four metrics endpoints respond, through Prometheus scraping and alert rules, to Alertmanager routing and a provisioned Grafana dashboard. Each step gives you a check before you move on, so a gap in one layer does not hide behind a working dashboard.
Confirm the four metrics Services respond
Before touching Prometheus, check that each metrics Service answers on its port: argocd-metrics on 8082 for the application controller, argocd-server-metrics on 8083 for the API server, argocd-repo-server on 8084, and argocd-commit-server on 8087. Port-forward each Service and request the metrics path, or run the same request from a pod inside the cluster. The step is done when all four return Prometheus text format. A missing commit server response usually means the component is not deployed in your Argo CD version, so confirm that against your install before assuming a fault.
Add scrape targets for each endpoint
Your platform team adds a scrape job for each of the four Services, either through a ServiceMonitor if you run the Prometheus Operator or through static or Kubernetes service discovery configuration in your Prometheus setup. Keep one job per component so the job label tells you which part of Argo CD a series came from. Apply the change through your normal configuration pipeline, not by editing a running Prometheus by hand. The step is done when the configuration reloads without errors.
Verify all targets are up in Prometheus
Open the Prometheus targets view and confirm that every Argo CD target shows as up with a recent last scrape. Then run a simple query such as a count of argocd_app_info series to confirm data is arriving. If a target is down, compare its scrape error with the Service check from the first step, since a wrong port or a network policy blocking Prometheus is the most common cause. The step is done when all four jobs are up and the query returns series.
Decide on application label exposure
Decide whether to expose application labels on metrics. This is off by default because it can raise label cardinality significantly, and each application adds its own series. Teams with a small number of applications may accept it for per-application dashboards, while larger installations usually keep it off and aggregate by project or sync status. Record the decision in your configuration, and ask your Argo CD operators to confirm how many applications and clusters they expect, since that number drives the cost of the choice.
Define alert rules on sync, health and reconcile signals
Write alert rules for the signals that show whether deployments are working. Use argocd_app_info filtered on sync_status and health_status to alert on applications that stay out of sync or degraded for longer than your team agrees is acceptable. Add rules for argocd_cluster_connection_status so a lost cluster connection pages someone, and for argocd_app_reconcile to catch a controller that is slow or stuck. Test each rule against the current state, and review the thresholds with the application owners, because the right wait time depends on how your teams deploy.
Route alerts through a clustered Alertmanager
Deploy Alertmanager as a cluster using its cluster flags so grouping, inhibition and silences hold across instances. Configure Prometheus to send alerts to every Alertmanager instance directly, not through a load balancer, as the Alertmanager documentation advises. Set routes for each team and an inhibition rule so a cluster outage does not generate a flood of application alerts. The step is done when a test alert from a rule reaches your receiver and a silence created on one instance is visible on the others.
Import the example dashboard through provisioning
Take examples/dashboard.json from the Argo CD repository and load it into Grafana through a dashboard provider file, so the dashboard is version-controlled alongside the rest of your monitoring configuration. Point its data source variable at your Prometheus data source, and check that each panel renders data. Treat the dashboard as a starting point, and adjust panels to match the alert rules you wrote. The step is done when Grafana restarts cleanly, the dashboard appears from the provisioned file, and its panels show current Argo CD values.
Which Argo CD metrics deserve an alert
Start from the operational question, then pick the metric that answers it. For Argo CD, four series cover most of what an on-call team needs to know: argocd_app_info, with its sync_status and health_status labels, tells you whether an application is OutOfSync or Degraded right now. argocd_app_sync_total shows how often syncs run and with what result, which is how you spot a sync that keeps failing. argocd_app_reconcile reflects the controller's reconciliation work, so a rise in its latency or volume points to a controller under pressure rather than a broken application. argocd_cluster_connection_status answers whether a destination cluster is reachable at all, which matters most when a registered cluster silently stops receiving changes.
Map each question to a rule you can read back. Is production OutOfSync is a question about argocd_app_info filtered to production applications and a sync_status other than Synced. Is a Degraded app stuck is a question about health_status staying at a non-healthy value across consecutive evaluations, not a single sample. Is a cluster disconnected is a question about argocd_cluster_connection_status remaining at its failure value. Are syncs failing repeatedly is a question about the rate of failed results from argocd_app_sync_total, which is easier to read as a ratio or increase over a window than as a raw counter. Each of these rules carries a label scope, so confirm in your environment which label set you actually expose before writing the expression, since application labels are off by default and changing that setting affects cardinality.
The thresholds, the durations (how long a state must persist before paging), the severity of each alert and the routing to a team or channel are decisions your owning team sets, tests and revisits. The Argo CD documentation does not supply default alert thresholds, and this page does not offer them. Test each rule against a deliberately broken staging application and a paused test cluster before relying on it, and confirm that expected OutOfSync states during planned maintenance will not page anyone. Record who owns each rule, how an alert is acknowledged, and which runbook it links to. Alertmanager routing and silences should be reviewed in the same change, because an alert that reaches no one is not monitoring.
How Argo CD metric labels map to what teams monitor
This table maps the Argo CD metrics and labels most teams alert on to the component that emits them, the operational question each one answers and the cardinality risk it carries. Read it before you enable application labels or build alert rules, because the risk column shows where series counts can grow with your application count.
| Metric or label | Emitted by | Question it answers | Cardinality risk |
|---|---|---|---|
| argocd_app_info (sync_status, health_status) | Application controller | How many applications are Synced, OutOfSync, Healthy or Degraded right now? | Low: one series per application and status combination, so it grows with application count |
| argocd_app_sync_total | Application controller | How often are syncs running, and do they succeed or fail? | Low to moderate: counter series grow with applications and the sync result labels |
| argocd_app_reconcile | Application controller | How long does reconciliation take, and is the controller falling behind? | Moderate: histogram buckets multiply series, so review it when application count rises |
| argocd_cluster_connection_status | Application controller | Can Argo CD reach each registered destination cluster? | Low: one series per registered cluster, so it tracks cluster count |
| Application labels on metrics | Application controller (opt-in) | Which team or application owns a metric series? | High: exposing application labels is off by default because it can raise cardinality significantly |
| API server request metrics | API server (port 8083) | Are users and automation hitting the UI and API, and are requests failing? | Moderate: depends on route and status labels, so confirm the exposed label set in your version |
| Repo-server metrics | Repo-server (port 8084) | Is manifest generation slow or failing for Helm and Kustomize sources? | Low to moderate: per-repository labels, if present, scale with repository count |
Label cardinality: where dashboards and Prometheus get expensive
Application-level labels make Argo CD metrics far more useful, and far more expensive to store. The cards below cover where that cost lands, how Prometheus handles it, and how to decide which labels earn their place before a dashboard or alert depends on them.
Application labels are off by default
Argo CD does not expose application labels on its metrics unless you turn that on, because each application adds its own label values. The metrics guide warns that enabling them can raise cardinality significantly. Before you enable anything, confirm which metrics carry application labels in your Argo CD version and which ones your dashboards actually query.
Series count grows with applications and clusters
Every unique combination of metric name and label values is a separate time series in Prometheus. Multiply application names by sync status, health status, namespace and destination cluster, and the count grows quickly as teams and clusters are added. A metric that looks cheap on a ten-application test can dominate memory on a fleet of hundreds.
Memory and disk limit one instance
Prometheus keeps recent series in memory and writes them to a local time series database in two-hour blocks. More series means more memory during ingestion and more disk for the retention window. Local storage is not clustered or replicated, so one Prometheus instance has a ceiling set by its own hardware, not by the number of Argo CD installations you run.
Prometheus favors reliability over precision
Prometheus documents that it values reliability over precision and is not suited to workloads that need every sample to be exact. For Argo CD, that means a dashboard showing sync state is a good fit, while per-application audit records are not. Keep that in mind when deciding whether an application-level label is worth its cost compared with querying the Argo CD API or logs.
Keep labels on a few high-value metrics
Enable application labels only on the metrics that answer a question you act on, such as the sync and health state that drives an on-call alert. Leave the rest at their default labels. Some teams also drop high-cardinality labels at scrape time with metric relabeling, which keeps the source unchanged while limiting what Prometheus stores. Test that the alerts still fire after the change.
Measure series counts before and after
Record the number of active series for Argo CD jobs before you enable labels, then again after a full scrape cycle under typical load. Use the Prometheus UI or a query that counts series per metric name, and check the per-metric breakdown to find the largest contributors. Set a series budget for the Prometheus instance, and alert when the count approaches it.
Running Prometheus and Grafana: single instance, HA or external storage
A single Prometheus server is the simplest way to start scraping the four Argo CD metrics endpoints. It stores samples on local disk in a time series database, and its default retention is 15 days, which you can change by time or by size. Local storage is not clustered or replicated, so the server should be run and backed up like any other single-node database. Losing the host means losing the history it holds, but Argo CD itself keeps no state in Prometheus, so the GitOps configuration is unaffected.
- Retention sizing: Set retention by time or size to match how far back your reviews and incident work need to look, and confirm the disk can hold it.
- Backup plan: Snapshot or copy the data directory on a schedule you document, and test a restore on a separate host.
- Scrape scope: Scrape the controller, API server, repo-server and commit server endpoints so a single failure does not hide the whole picture.
- Failure window: Accept that metrics are lost or gapped while the host is down, and tell alert owners that paging depends on this one server.
Before you choose this option, ask your team who restores the server, how long a restore takes, and whether that gap is acceptable for the Argo CD environments you run.
Running two Prometheus servers that scrape the same targets gives you two independent copies of the data, so one host can fail without a gap in the dashboards. The two servers do not share storage or coordinate with each other, so each keeps its own history. Alerting needs care here, because each server evaluates rules and sends alerts on its own. Alertmanager can run as a cluster through its cluster flags, and Prometheus should be configured to point at every Alertmanager instance rather than a load balancer in front of them.
- Duplicate scraping: Both servers load the same load on the Argo CD endpoints, so size the scrape interval and label set for both.
- Alert path: Confirm that Alertmanager receives alerts from both Prometheus servers and that grouping and silences behave the same on each.
- Query consistency: Expect small differences between the two copies around scrape timing, and decide which one dashboards read by default.
- Operational ownership: Assign a team to upgrade and monitor both servers, since each one is a separate database to run.
Before you choose this option, confirm the Alertmanager cluster design with your alerting owners and check that both Prometheus servers are actually scraping and alerting.
Remote write lets Prometheus send samples to an external long-term storage system, so history can outlive the local retention window and the local disk. Prometheus supports remote write and remote read protocols for this purpose. The Prometheus servers still scrape and evaluate rules locally, so the local instance remains the first point of failure for alerting. The external store adds its own platform to run, secure, size and back up, and the total cost depends on the storage system you pick and the sample volume it receives.
- Scope of the store: Decide whether the external store is for audit history, capacity planning or cross-cluster queries, since each use case changes retention needs.
- Local still matters: Keep rule evaluation and paging on the local Prometheus unless you have verified the remote path for alerts.
- Network and credentials: Plan TLS and authentication for the remote write path, and keep those credentials out of Git.
- Outage behavior: Confirm how Prometheus buffers and retries when the remote endpoint is down, and what data is lost if the buffer fills.
Before you choose this option, ask the storage vendor or project for its supported remote write version, its retention and sizing model, and its backup and restore process.
A single Grafana server stores its configuration in SQLite 3 by default, which is the lowest-effort way to try dashboards. The Grafana installation docs state that SQLite does not scale for production. The installation docs also size small deployments at under 25 concurrent users with 2 cores and 2 to 4 GB of RAM. This option suits a lab, a proof of concept or a personal evaluation of the Argo CD dashboard, and it should not carry the on-call view for production clusters.
- Production limit: Move to MySQL or PostgreSQL before production use, because SQLite is not a production database.
- Dashboard source: Start from the example dashboard in the Argo CD repository, then adjust panels to your environments.
- Provisioning: Define data sources and dashboards as files so a rebuild restores the same setup.
- Single point of failure: If the Grafana host is lost, the dashboards and their history must be rebuilt or restored from backup.
Before relying on this setup, ask your team what backup covers the SQLite file and who would rebuild the server during an incident.
Grafana high availability uses two or more active-active servers behind a load balancer, all sharing a MySQL 8.0 or later or PostgreSQL 12 or later database. Database-backed auth tokens let users reach any node, so a node can fail without a login loss. The database becomes a central component that needs its own backups, failover and patching. Grafana Live has limitations in an HA setup, so confirm that any live streaming features you plan to use work in your topology.
- Alerting duplicates: Alerting needs extra configuration to avoid duplicate notifications when several servers evaluate the same rules, so test that before go-live.
- Database operations: Plan backups, restore tests and version upgrades for the shared database, and treat it as the source of truth.
- Load balancer and sessions: Confirm health checks and session behavior at the load balancer with your chosen authentication method.
- Authentication scope: SAML, team sync, active sync and SCIM are available only in Grafana Enterprise and Grafana Cloud, so check which login methods your edition supports.
Before you commit to this option, ask who operates the database, how Grafana alerting is de-duplicated in your design, and which Grafana edition the requirements call for.
Securing the monitoring path
Metrics, dashboards and alerts describe how your deployment behaves and what it runs, so they need the same access controls as the Argo CD installation itself. The cards below cover the Grafana front end, the network paths into Argo CD's metrics services, and the data that dashboards and alert annotations expose.
Require authentication on metrics
Grafana's hardening guidance recommends requiring authentication for its metrics endpoint, so an unauthenticated caller cannot read version details or internal counters. Check this setting in your Grafana configuration and test it from outside the cluster with no credentials. The same question applies to the Prometheus query and API endpoints, which should sit behind your ingress or internal network with authentication in front of them. Confirm the behavior with your own deployment before you rely on it.
Apply Grafana hardening settings
Enable secure and SameSite cookies, set a Content Security Policy and Trusted Types, and hide the Grafana version from unauthenticated users. Add domain verification so that requests for an unexpected host name are rejected, which blocks DNS rebinding against the dashboard. Record each setting in your configuration repository so reviewers can see the values in version control. Ask your security team to test the policy against the dashboards you actually use, since a strict policy can break panels that load external scripts.
Use SSO for Grafana access
Grafana supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT in all editions, so most teams can reuse the identity provider already in front of Argo CD. SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so check that before designing group-based access. Disable local admin logins once SSO works, and keep a documented break-glass path. Confirm the exact auth method and group mapping with your identity team.
Restrict network access to metrics
The Argo CD metrics services listen on argocd-metrics:8082, argocd-server-metrics:8083, argocd-repo-server:8084 and argocd-commit-server:8087. Use Kubernetes NetworkPolicies so that only the Prometheus scraper can reach these ports, and deny access from other namespaces by default. Review whether the repo-server metrics port should be reachable at all outside the scraper. Confirm that your CNI enforces NetworkPolicy before you treat these rules as a control.
Treat dashboards as sensitive data
Dashboards and alert annotations often include application names, namespaces, cluster names and sync status for production workloads. Limit who can edit dashboards and who can view folders that show per-application panels, since a viewer can read those labels. Avoid placing secrets, tokens or internal hostnames in alert text or annotation fields. Review the example dashboard before adopting it, and remove panels or labels that your reviewers do not need.
Protect Prometheus and Alertmanager storage
Prometheus local storage is not clustered or replicated, so a compromised or damaged host exposes the full history of collected metrics. Restrict filesystem and host access to the Prometheus pods, and limit who can change scrape configuration or alert routing. Alertmanager receives notifications from every Prometheus instance, so restrict its API and secure the webhook and chat credentials it holds. Ask your platform team who owns these credentials and how they rotate.
Common monitoring failures and how to fix them
This table pairs each common failure in an Argo CD monitoring setup with its likely cause and the fix to try first. Read it while a dashboard or alert is misbehaving, starting with the row that matches your symptom. Most failures trace back to scrape configuration, label settings or a data source that was never wired up.
| Symptom | Likely cause | Fix |
|---|---|---|
| Targets down for argocd-metrics or argocd-server-metrics | Scrape config points at the wrong Service name, namespace or port (for example, expecting 8082 on the API server Service instead of 8083) | Match each target to its Service and port: application controller on 8082, API server on 8083, repo-server on 8084, commit server on 8087. Confirm in the Prometheus targets page. |
| argocd_app_info returns no series | The application controller metrics endpoint is not scraped, so the app-level gauges never reach Prometheus | Add a scrape job for argocd-metrics:8082 and confirm the target is up before writing sync or health alerts. |
| Metrics missing or renamed after an upgrade | Service names, ports or labels changed in a new Argo CD release, or the scrape job still references an older manifest | Compare the current installation manifests with your scrape config after each upgrade and check the release notes for changed metric names. |
| Prometheus memory grows steadily | Application labels are exposed on metrics, multiplying series count per application and per label value | Keep application label exposure off unless you need it, drop unneeded labels with metric relabeling, and watch series count after each change. |
| Duplicate Grafana alert notifications in HA | Each Grafana node evaluates alert rules and sends notifications, so every instance fires the same alert | Apply the HA alerting configuration described in the Grafana high availability docs and confirm one notification per alert in a test channel. |
| Dashboard panels empty after importing examples/dashboard.json | The dashboard's data source variable is unset or points to a Prometheus instance that does not hold Argo CD metrics | Set the Prometheus data source variable at the top of the dashboard and confirm the Argo CD series return data in Explore. |
| Cluster connection gauges show stale values | Metrics for a removed or unreachable cluster persist, or the controller has stopped reporting so the last value is held | Check the argocd_cluster_connection_status series against the cluster list, alert on absent series, and confirm the controller target is still up. |
Questions teams ask before monitoring Argo CD
What does it cost to monitor Argo CD with Prometheus and Grafana?
The software is free to use: Argo CD, Prometheus and Grafana OSS are all open-source projects, and none of them has a paid edition from its project that you must buy to run metrics and dashboards. The cost comes from the infrastructure that runs Prometheus and Grafana, the storage for metrics, the time to implement and tune scraping, alerts and dashboards, and the people who keep them running. Ask any partner for a quote that separates one-time implementation from recurring infrastructure, storage and operations, and that states which environments and alert channels are in scope.
What drives the cost of metrics storage up or down?
Storage grows with the number of active time series, the scrape interval and the retention you choose. Prometheus keeps data in a local time series database with a default retention of 15 days, configurable by time or size, and its storage documentation says local storage is not clustered or replicated. Exposing application labels on Argo CD metrics is off by default because it can raise cardinality significantly, so enabling it is a deliberate cost decision. If you need longer history, plan remote write to external long-term storage and price that component separately.
How long does a monitoring implementation take?
Duration depends on how many clusters report to Argo CD, whether Prometheus and Grafana already exist in your environment, how many alert routes and owners must be defined, and how much dashboard work your teams want beyond the example. Scraping the four Argo CD metrics endpoints on an existing Prometheus is usually the smallest part. Alert design, agreeing thresholds with the teams that own each application, and validating notifications take longer. Ask for a written scope with a timeline that lists these phases, because no fixed duration applies to every environment.
What does your team need to provide before the work starts?
Plan to provide four things: access to the clusters where Argo CD runs and to the namespaces that hold its metrics services, network paths from Prometheus to the endpoints on ports 8082, 8083, 8084 and 8087, a place to run Grafana with a database suited to production, and named alert owners who will accept pages and act on them. Grafana's installation documentation says SQLite does not scale for production, so MySQL or PostgreSQL is required for production and high availability. Confirm credentials for any data source and who approves changes to scrape configuration.
Can a platform team monitor Argo CD without a partner?
Yes, a platform team with Kubernetes and Prometheus experience can do this in-house, and the open-source tooling does not require a partner to be installed. The harder parts are usually the ones outside the tools: deciding which sync and health states page someone, avoiding noisy alerts, keeping cardinality under control, and documenting who responds. A partner is most useful when those decisions need an outside review or when the team lacks capacity. Whichever route you choose, agree on owners for scrape configuration, dashboards and alert rules before the build starts.
Which Grafana edition do we need for SSO?
Single sign-on that uses SAML, team sync, active sync or SCIM provisioning requires Grafana Enterprise or Grafana Cloud. According to Grafana's authentication documentation, all editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. If your identity provider speaks OIDC, check whether the generic OAuth option meets your needs before buying Enterprise. Confirm the edition and license terms with Grafana Labs directly, because licensing terms are part of the decision.
How does Grafana Cloud pricing compare with self-hosting?
The comparison depends on usage, so the supplied figures only frame the question. Grafana's pricing page lists a free tier, a Pro tier that starts with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year. Self-hosting shifts cost to your infrastructure, storage and staff time. Ask for metrics volume estimates from your own clusters, then compare usage-based Cloud charges with the infrastructure and operations cost of running Prometheus and Grafana in your environment.
How DeployOpen scopes and supports Argo CD monitoring
Monitoring work is scoped in writing before it starts. A DeployOpen engagement for Argo CD monitoring is fixed-scope: the written scope names the Argo CD components to scrape (application controller, API server, repo-server and commit server), the Prometheus and Alertmanager instances that will collect and route signals, the alert rules, the Grafana dashboards and the access model, along with the deliverables and timeline agreed before work begins. Pricing follows from that scope. Ask for the scope to state which metrics are in and out, whether application-label exposure is enabled, and who owns each alert route after handover.
DeployOpen configures and documents the monitoring stack inside your own infrastructure, whether that is your cluster, your Prometheus servers or your Grafana instance. The deliverables typically include scrape configuration for the Argo CD metrics endpoints, alert rules tied to sync status, health status and cluster connection status, a provisioned dashboard built from the example in the Argo CD repository, and a runbook that explains each alert and its expected response. Confirm with us where the Grafana backing database, Prometheus retention and any remote-write destination will live, because those choices decide what the platform team operates after handover.
Ongoing tuning is available as a retainer. Metric cardinality, alert noise, dashboard changes after Argo CD minor upgrades and Prometheus or Grafana version updates are the items most likely to need periodic attention. A retainer covers that review work, while the one-time build covers the initial configuration. This monitoring work prepares dashboards, alerts and documented evidence of how Argo CD state is observed. It does not produce audit reports or certifications, and any assessment of your controls remains with your independent auditor.
How DeployOpen delivers Argo CD monitoring
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms in infrastructure you control. For Argo CD monitoring, we scope the metrics, dashboards and alerts in writing, build them into your clusters, and hand over runbooks your team can operate.
How we scope
- Inventory which Argo CD endpoints, clusters and applications the monitoring must cover before any build starts
- Agree in writing which alerts, dashboards and retention settings are in scope and which are excluded
- Confirm your Prometheus, Alertmanager and Grafana hosting model, license posture and access requirements first
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
How we build
- Configure scrape targets for the controller, API server, repo-server and commit server metrics endpoints
- Set label and cardinality limits on application metrics, then test query load against your expected application count
- Write alert rules for sync status, health status and cluster connection status, and route them through Alertmanager
- Provision Grafana data sources and dashboards as code so the setup can be reviewed and rebuilt from Git
How we hand over
- Verify each alert fires and clears in a controlled test, and record the results in the handover pack
- Document scrape configuration, dashboard versions, retention settings and the owner of each alert
- Walk your operations and platform team through triage steps for common Argo CD alerts
- Provide a written record of what was built, what was tested and what remains your responsibility
How we support
- Ongoing support, upgrades and monitoring reviews are available as a retainer after handover
- Track Argo CD and Prometheus or Grafana upgrades in your environment and plan changes to dashboards and alert rules
- Confirm with your team which support hours, response paths and escalation contacts apply before the retainer starts
- Review alert noise and metric growth periodically and adjust rules in the agreed scope
