How to fix ArgoCD orphaned in Kubernetes

KubernetesINTERMEDIATEMEDIUMUpdated Dec 6, 2025ยท 94 views

ArgoCD reports resources as orphaned when they exist in the cluster but are not tracked by any ArgoCD application. This happens after manual resource creation or application definition changes. Sync the application or adopt orphaned resources.

Quick fix

Fixes ArgoCD orphaned

argocd app resources YOUR_APP_NAME --orphaned
  1. View orphaned resources in the ArgoCD UI
  2. Decide whether to adopt or exclude resources
  3. Adopt resources by adding them to ArgoCD
  4. Exclude resources using orphanedResources ignore rules
kubernetes โ€” error
argocd app resources YOUR_APP_NAME --orphaned
ArgoCD orphaned

What this error means

In ArgoCD, "orphaned" resources are Kubernetes objects that exist in the cluster but are not defined in any Application's git repository. ArgoCD tracks resources it creates and manages, and flags untracked resources as orphaned. This can lead to resource leaks and unmanaged configuration drift.

Typical symptoms

  • ArgoCD UI shows "orphaned" resources warning
  • Resources exist in cluster but not in ArgoCD
  • Application sync shows orphaned resources
  • Deleting application leaves resources in cluster
  • Resource created manually is not managed by ArgoCD
  • Application does not recognize manually created resources
  • Pod events show resources owned by nothing

Common causes

  1. Resource created manually outside of GitOps
  2. Application definition changed, dropping resource
  3. Resource created by different controller not defined in git
  4. ArgoCD application removed without cleanup
  5. Ownership labels missing from resources
  6. Helm chart changed, removing resources from template
  7. Manual edits to cluster resources

How to fix "ArgoCD orphaned"

1View orphaned resources in the ArgoCD UI

Open the ArgoCD web interface and navigate to the Applications view. Look for a "Show Orphaned" option in the sidebar (typically with a count badge). Click it to see all orphaned resources in your cluster.

Alternatively, use the CLI to list orphaned resources:

bash
argocd app resources YOUR_APP_NAME --orphaned

This command only works if the resource was previously managed by the application. To see all orphaned resources across the entire cluster, access the ArgoCD UI.

2Decide whether to adopt or exclude resources

For each orphaned resource, determine if it should be:

1. Adopted: Add the resource to your ArgoCD Application by including it in your git repository
2. Excluded: Ignore the resource as it is intentionally managed outside ArgoCD
3. Deleted: Remove the resource if it is no longer needed

Most commonly, resources created by operators (like cert-manager secrets) should be excluded from monitoring, while resources you want to manage should be adopted.

3Adopt resources by adding them to ArgoCD

To adopt an orphaned resource, add it to your ArgoCD Application configuration:

1. Define the resource in your git repository (in the same Helm chart or kustomize base as your Application)
2. Ensure the resource path is included in your Application spec
3. Sync the Application

Example ArgoCD Application that includes the resource:

yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  source:
    repoURL: https://github.com/myorg/myrepo
    path: k8s/
  destination:
    server: https://kubernetes.default.svc
    namespace: default

Make sure the resource YAML is in the k8s/ directory so ArgoCD tracks it.

4Exclude resources using orphanedResources ignore rules

To prevent specific resources from being marked as orphaned, add them to your AppProject's orphanedResources ignore list:

yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: default
spec:
  orphanedResources:
    warn: true
    ignore:
    - group: cert-manager.io
      kind: Certificate
      name: my-cert
    - group: ""
      kind: ConfigMap
      name: kube-root-ca.crt

Or use the CLI:

bash
argocd proj set default --add-orphaned-ignore='{"group":"cert-manager.io","kind":"Certificate","name":"my-cert"}'

This is ideal for resources intentionally managed outside ArgoCD (e.g., secrets created by operators).

5Delete orphaned resources if necessary

If an orphaned resource should no longer exist, delete it from your cluster:

bash
kubectl delete RESOURCE_TYPE RESOURCE_NAME -n NAMESPACE

Example:

bash
kubectl delete deployment old-service -n production

Warning: Only delete resources you are certain are no longer needed. Some orphaned resources (like cert-manager certificates) should be excluded instead of deleted.

6Enable or disable orphaned resource warnings

By default, ArgoCD warns about orphaned resources. To disable warnings (but still allow viewing orphaned resources in the UI):

yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: default
spec:
  orphanedResources:
    warn: false

To re-enable warnings:

bash
argocd proj set default --orphaned-resources-warn

Keep warnings enabled to maintain visibility into unclaimed resources in your cluster.

7Review and fix resource tracking method conflicts

If you recently changed the resource tracking method (annotation vs. label), orphaned resources may appear temporarily:

1. Check your ArgoCD ConfigMap for the tracking method setting:

bash
kubectl get configmap argocd-cm -n argocd -o yaml | grep resourceTrackingMethod

2. If you changed it and deleted the application before syncing, recreate the application
3. Sync the application to re-establish tracking labels/annotations
4. Verify orphaned resources are reassociated with the application

This is a temporary issue that resolves after re-syncing with the new tracking method.

Advanced notes

Operator-Created Resources: Operators like cert-manager, external-secrets, or service-mesh controllers automatically create resources. These are legitimate orphaned resources and should be excluded from monitoring using the orphanedResources ignore list rather than being adopted.

Resource Tracking Methods: ArgoCD supports two methods for tracking resource ownership: annotations (legacy) and labels (current). If you switch methods, resources may temporarily appear orphaned until the application is re-synced.

Finalizer Issues: If an Application deletion is stuck and cannot be cleaned up, orphaned resources may prevent proper cleanup. Remove finalizers with care:

bash
kubectl patch application/APP_NAME --type json --patch='[{"op":"remove","path":"/metadata/finalizers"}]'

Large-Scale Cleanup: For clusters with many orphaned resources from a migration, consider using ArgoCD in "auto-prune" mode initially and then transition resources to git-managed sources systematically.

Multi-Cluster Scenarios: In hub-and-spoke or multi-cluster setups, use AppProject-level ignore rules consistently across clusters to prevent warning fatigue from expected orphaned resources.

Frequently asked questions

What does "ArgoCD orphaned" mean?
In ArgoCD, "orphaned" resources are Kubernetes objects that exist in the cluster but are not defined in any Application's git repository. ArgoCD tracks resources it creates and manages, and flags untracked resources as orphaned. This can lead to resource leaks and unmanaged configuration drift.
How do I fix "ArgoCD orphaned"?
ArgoCD reports resources as orphaned when they exist in the cluster but are not tracked by any ArgoCD application. This happens after manual resource creation or application definition changes. Sync the application or adopt orphaned resources.
What causes "ArgoCD orphaned"?
Resource created manually outside of GitOps Application definition changed, dropping resource Resource created by different controller not defined in git
Is the "ArgoCD orphaned" error serious?
It is a medium-severity error โ€” more of a blocker than a risk. The steps above resolve it.

Official resources & further reading