Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Introducing Argo CD to bring the deployment state into Git and give us a single source of truth for what was actually running in each environment. The onboarding was straightforward for teams already using Helm. The real learning came later, once Argo CD was managing enough applications that we started seeing it struggle under load. Before getting into those fixes, it helps to understand what Argo CD is actually doing under the hood and why it works differently from a traditional push-based deployment model.


1. GitOps vs Traditional

In the traditional model, a developer runs kubectl apply directly against a Kubernetes cluster. The cluster has no memory of how a resource got there or whether it matches anything in source control. If someone makes a manual change to a running deployment, there is no automatic correction. The cluster state and the desired state in Git quietly diverge, and nobody notices until something breaks. GitOps flips this. The developer commits to a Git repository. A deployment agent watches that repository and continuously compares what is in Git with what is running in the cluster. If they differ, the agent reconciles the cluster back to the desired state. The cluster never drifts silently because the agent is always watching. Argo CD is that deployment agent. It runs inside your cluster, watches your Git repositories, and keeps your applications in sync. This is fundamentally different from a push-based CI/CD pipeline. Argo CD is always running, always reconciling, always comparing. At small scale that is invisible. At large scale, the continuous nature of what it does is exactly where the performance problems come from.


2. How it fits into Your CI/CD Pipeline

Argo CD handles the CD half of the pipeline. The CI side is separate, your existing GitHub Actions, Jenkins, or any other CI tool handles unit tests, artifact builds, image builds, and pushing to an image registry. Once the CI pipeline completes, it updates the container image tag in the manifests or Helm chart values file and raises a pull request against your GitOps repository. Once that PR is merged, Argo CD detects the change and syncs the cluster to the new state. Argo CD is not just running on merges. It is constantly polling Git, generating manifests, comparing cluster state, and updating application statuses for every application it manages, continuously. When you manage ten applications this is invisible. When you manage a thousand, each of these operations compounds and the bottlenecks become very real.


3. Performance Problems and How to Fix Them

Workqueue Depth Piling Up: The application controller has a workqueue it uses to process reconciliation tasks. When more tasks arrive than the controller can process, the queue depth grows. Applications sit waiting to be reconciled, syncs feel delayed, and the dashboard shows stale status for longer than expected. Fix: Increase # of operation processors and status processors 


                        argocd-application-controller
                        apiVersion: vl
                        kind: ConfigMap
                        metadata:
                        labels:
                        app.kubernetes.io/name: argocd-cmd-params-cm
                        app.kubernetes.io/part-of: argocd
                        name: argocd-cmd-params-cm
                        data:
                        # STATUS PROCESSORS
                        controller.status.processors: '500'
                        # OPERATION PROCESSORS
                        controller.operation.processors: '250'
Rule of Thumb
For every 1000 applications:
--status-processors = 50
--operation-processors = 25