ArgoCD etcdserver: request is too large — Application exceeds 1 MB limit

This runbook is part of a series on ArgoCD sync failures. See also: HPA OutOfSync loop and operation deadlock. For broader GitOps context, read our post on GitOps and ArgoCD.

Symptoms

The argocd-application-controller logs show:

# Error in argocd-application-controller logs:
# rpc error: code = ResourceExhausted desc = etcdserver: request is too large

kubectl get application <APP_NAME> -n argocd -o json | wc -c
# Output > 1048576 (1 MB) = problem confirmed

The Application never reaches Synced status. Every sync attempt fails with the same error. ArgoCD UI may show Unknown or Syncing status without progress.

Cause

Every Kubernetes object (including the Application CRD) is stored in etcd, which has a hard limit of 1.5 MB per object (defaulting to 1 MB in many distributions). ArgoCD stores not just configuration in the Application CRD, but also:

• .status.history — full history of previous syncs (manifests, parameters, results)
• .status.resources — list of all managed resources and their state
• managedFields — Kubernetes metadata tracking who changed which field

With large Helm charts (100+ resources) or long sync history, the Application CRD grows beyond the etcd limit. The problem compounds over time as each sync adds a history entry. The default revisionHistoryLimit is 10, but in environments with frequent deployments (several per day), history accumulates quickly.

An additional factor is managedFields — metadata added by Kubernetes server-side apply. Every field in every managed resource has an entry about who last modified it. With hundreds of resources, this metadata alone can take up hundreds of kilobytes.

Fix

A) Reduce sync history (immediate relief):

# Check current history size
kubectl get application <APP_NAME> -n argocd \
  -o jsonpath='{.status.history}' | wc -c

# Patch: reduce history to last 3 entries
kubectl patch application <APP_NAME> -n argocd --type merge -p '
{
  "spec": {
    "revisionHistoryLimit": 3
  }
}'

# Force cleanup of existing oversized history
kubectl get application <APP_NAME> -n argocd -o json | \
  jq '.status.history = .status.history[-3:]' | \
  kubectl apply -f -

B) Configure resource.customizations in argocd-cm ConfigMap:

# argocd-cm ConfigMap patch — strip managedFields from tracked resources
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  resource.customizations.ignoreDifferences.all: |
    managedFields:
      - manager: "*"
  resource.compareoptions: |
    ignoreResourceStatusField: all

# Apply and restart repo-server to pick up changes
kubectl apply -f argocd-cm-patch.yaml
kubectl rollout restart deployment argocd-repo-server -n argocd

C) Split large Application into smaller ones (ApplicationSet):

If your Helm chart manages over 100 resources, consider splitting into logical groups. ApplicationSet lets you generate multiple Applications from a single template:

# Instead of one monolithic Application with 200+ resources,
# split into logical groups using ApplicationSet
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: platform-components
  namespace: argocd
spec:
  generators:
    - list:
        elements:
          - chart: networking
            path: charts/networking
          - chart: monitoring
            path: charts/monitoring
          - chart: workloads
            path: charts/workloads
  template:
    metadata:
      name: "platform-"
    spec:
      project: default
      source:
        repoURL: https://github.com/org/infra.git
        targetRevision: main
        path: ""
      destination:
        server: https://kubernetes.default.svc
        namespace: ""
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Splitting into smaller Applications has an additional benefit: individual resource groups sync independently, reducing single sync operation time and improving DORA metrics (deployment frequency, lead time for changes).

Validation

# 1. Verify Application resource size is under 1 MB
kubectl get application <APP_NAME> -n argocd -o json | wc -c
# Expected: < 1048576

# 2. Verify sync status is Synced
argocd app get <APP_NAME> --output json | jq '.status.sync.status'
# Expected: "Synced"

# 3. Verify health status
argocd app get <APP_NAME> --output json | jq '.status.health.status'
# Expected: "Healthy"

# 4. Check controller logs for recurring errors
kubectl logs statefulset/argocd-application-controller -n argocd \
  --since=5m | grep -c "error"
# Expected: 0 or minimal

If the Application size drops below 1 MB and sync completes without errors, the problem is resolved. Monitor for a few reconciliation cycles (3-5 minutes) to confirm the object doesn’t grow back.

CI/CD pipeline blocking your team?

Book a free 30-minute call. We'll review your ArgoCD configuration and pinpoint what to fix right away.

Book a call