# kubectl delete -l: Usage, Options & Common CI Errors

> kubectl delete -l removes every resource matching a label. Scoped teardown in CI, the dangerous broad-selector mistake, and the empty-match no-op.

Source: https://latchkey.dev/learn/command-reference/kubectl-delete-selector  
Updated: 2026-06-25

Delete every resource carrying a given label in one command.

kubectl delete -l removes all resources of a type that match a label selector - the idiom for tearing down everything a CI run created when you tagged it consistently. Scoping the selector tightly is what keeps it safe.

## What it does

kubectl delete TYPE -l key=value deletes every matching object of that type. Combine selectors with commas for AND (run=ci,pr=42). It honours graceful termination like any delete, and -n scopes it to a namespace; without -n it acts on the current namespace only.

## Common usage

```Terminal
kubectl delete pods -l app=web
kubectl delete all -l run=ci,pr=${PR_NUMBER}
kubectl delete deploy,svc,cm -l release=preview-${PR_NUMBER}
kubectl delete pods -l app=web --dry-run=client       # preview the match
```

## Common errors in CI

The dangerous mistake is an over-broad or empty selector: a typo that drops the selector entirely turns delete pods -l '' into delete pods (everything in the namespace), so always --dry-run=client the selector first and scope teardown to a dedicated namespace you can simply delete instead. delete all -l does NOT cover every kind - "all" is a curated set (pods, services, deployments, etc.) and misses ConfigMaps, Secrets, PVCs, and CRDs, so a namespace can look empty while those linger. A selector matching nothing prints "No resources found" and exits 0, which can mask a labelling bug.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl delete -l: Usage, Options & Common CI Errors?

kubectl delete -l removes all resources of a type that match a label selector - the idiom for tearing down everything a CI run created when you tagged it consistently. Scoping the selector tightly is what keeps it safe.

### What it does?

kubectl delete TYPE -l key=value deletes every matching object of that type. Combine selectors with commas for AND (run=ci,pr=42). It honours graceful termination like any delete, and -n scopes it to a namespace; without -n it acts on the current namespace only.

### Common errors in CI?

The dangerous mistake is an over-broad or empty selector: a typo that drops the selector entirely turns delete pods -l '' into delete pods (everything in the namespace), so always --dry-run=client the selector first and scope teardown to a dedicated namespace you can simply delete instead.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt