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.
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.
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:
argocd app resources YOUR_APP_NAME --orphanedThis 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.
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.
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:
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: defaultMake sure the resource YAML is in the k8s/ directory so ArgoCD tracks it.
To prevent specific resources from being marked as orphaned, add them to your AppProject's orphanedResources ignore list:
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.crtOr use the CLI:
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).
If an orphaned resource should no longer exist, delete it from your cluster:
kubectl delete RESOURCE_TYPE RESOURCE_NAME -n NAMESPACEExample:
kubectl delete deployment old-service -n productionWarning: Only delete resources you are certain are no longer needed. Some orphaned resources (like cert-manager certificates) should be excluded instead of deleted.
By default, ArgoCD warns about orphaned resources. To disable warnings (but still allow viewing orphaned resources in the UI):
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: default
spec:
orphanedResources:
warn: falseTo re-enable warnings:
argocd proj set default --orphaned-resources-warnKeep warnings enabled to maintain visibility into unclaimed resources in your cluster.
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:
kubectl get configmap argocd-cm -n argocd -o yaml | grep resourceTrackingMethod2. 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.
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:
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.
No subnets found for EKS cluster
How to fix "eks subnet not found" in Kubernetes
unable to compute replica count
How to fix "unable to compute replica count" in Kubernetes HPA
error: context not found
How to fix "error: context not found" in Kubernetes
default backend - 404
How to fix "default backend - 404" in Kubernetes Ingress
serviceaccount cannot list resource
How to fix "serviceaccount cannot list resource" in Kubernetes