Argo CD

A sync operation removed ConfigMaps used by another team, causing two services to restart with missing configuration.

ArgoCD shows one or more applications as perpetually 'OutOfSync' even immediately after a successful sync operation completes. The sync status flips from Synced to OutOfSync within seconds. The ArgoCD UI diff view shows differences in fields that are not defined in the Git manifests, such as added annotations, modified resource limits, injected sidecar containers, or defaulted fields. The continuous sync attempts generate excessive API server load and flood the ArgoCD notification channels with sync-started/sync-completed events every 30-60 seconds.

All ArgoCD applications across every project simultaneously transition to a 'SyncFailed' status. The ArgoCD UI shows a red error banner on every application. No new syncs can complete, and auto-sync applications that were previously healthy are now stuck. The error consistently references Git repository access failure. The issue affects all applications regardless of the target cluster or namespace.

ArgoCD reports specific resources as OutOfSync even though the live manifest in the cluster matches the Git manifest exactly when compared manually with kubectl diff. The ArgoCD diff view shows differences in metadata.managedFields or in fields that appear identical but differ in field ordering, empty vs null values, or default values applied by the API server. The issue affects only certain resource types (Services, Deployments with specific annotations) and started appearing after a Kubernetes version upgrade.

ArgoCD application syncs for the checkout-worker service timeout after 90 seconds and eventually fail. The ArgoCD repo-server pods are repeatedly OOM killed and restarted by Kubernetes. Other applications using simple Kustomize or plain YAML manifests continue to sync normally. The issue started after the checkout-worker Helm chart added three new subchart dependencies.

A developer deleted an ArgoCD Application resource intending to reconfigure it, and Kubernetes immediately began terminating all pods, services, configmaps, secrets, and other resources that the Application had managed in the production namespace. The payments-api service went down completely as its Deployment, Service, Ingress, HPA, and PDB were all deleted within seconds. The production outage lasted 25 minutes until the resources were recreated.

Production applications managed by ArgoCD showed Synced and Healthy status for weeks, but a manual audit revealed that several resources had drifted significantly from their Git-defined desired state. Resource limits had been changed via kubectl edit, environment variables had been manually added, and replica counts had been overridden outside of Git. ArgoCD did not detect or report any of these changes, creating a false sense that GitOps was being enforced.

GitOps reconciliation is safest when one Application owns a clear set of resources. Broad paths, shared namespaces, and automated prune can delete objects that another team assumes are outside the app boundary. Without following this practice, teams typically discover the problem during a production incident. The cost of fixing issues reactively is 10-100x higher than preventing them proactively. This becomes especially dangerous at scale when multiple teams depend on the same infrastructure, because one team's shortcut becomes another team's outage. Organizations that skip this practice often find themselves in a cycle of firefighting instead of building. The pattern is predictable: it works fine in development, survives staging, and fails spectacularly in production under real traffic and real failure conditions.