Clean up abandoned workloads

A quarterly cleanup turns up the same three patterns: a side-project that shipped two years ago and still has three replicas, a staging deployment of a service that was retired in February, and a backup tool nobody remembers naming. Kubeadapt's Abandoned Workloads page surfaces all three. This guide is about reading the signals correctly so you delete what's safe and leave what isn't.

1. Open the Abandoned Workloads page

Clusters → pick a cluster → Abandoned Workloads in the cluster nav.

Each row shows a workload Kubeadapt has flagged based on three signals over the last 14 days:

• Network activity — ingress, egress, and connection rate. A workload nobody talks to is suspicious.
• Resource efficiency — CPU and memory usage vs. requests. Workloads sitting at < 5% of requested CPU rarely earn their keep.
• Last active — when activity was last observed.

Kubeadapt computes a status from those signals and assigns each workload to one of three buckets.

2. Read the status column

The status filter at the top splits workloads three ways:

Start with Safe to scale down. Sort by Current Monthly Cost descending — the goal is to free real money, not chase $4 deployments.

3. Distinguish forgotten from intentional

Click a workload to open the detail panel. The signals view shows raw numbers — ingress bytes per hour, CPU usage percentile, last active timestamp. Cross-check against three things you know about your environment:

• Cron-like patterns. A workload with zero activity on weekdays but heavy spikes on Sundays at 2 a.m. is a scheduled job, not abandoned. Look at the time series, not just the 14-day average.
• Disaster recovery and standby. Standby replicas of stateful services exist precisely to do nothing until they're needed.
• Owned by someone who left. The Owner column comes from the owner Kubernetes label (configurable in Settings → Label Keys). If it's empty or points to a former employee, that's a flag — but not by itself a reason to delete.

If a workload is intentionally idle, leave it running. Kubeadapt doesn't track per-workload exceptions in the UI, so the durable answer is to capture intent in a label your team agrees on:

metadata:
  labels:
    team: data-platform
    owner: ops@example.com
    workload-purpose: dr-standby

A consistent workload-purpose label gives owners a one-line answer to "why is this still here?" the next time someone reviews this page.

4. Scale down or delete the rest

For workloads you've confirmed as abandoned, scale to zero first, watch for 48 hours, then delete. Scaling to zero is reversible; deletion is not.

# Scale to zero, keep the manifest for one weekly cycle
kubectl scale deployment <name> -n <namespace> --replicas=0

# After 48-72 hours with no escalations, delete
kubectl delete deployment <name> -n <namespace>

For StatefulSets with PVCs, scaling to zero leaves storage costs in place. After deletion, clean up the PVCs separately — the Orphaned Resources page surfaces these once they're detached from any workload.

5. Confirm the savings

Refresh the page after the 14-day signal window catches up. Deleted workloads disappear; scaled-to-zero workloads remain visible with Current Monthly Cost: $0 until they're removed. Cost Explorer's namespace view shows the cluster-level reduction within a day of the change.

Next steps

• Abandoned workloads concepts — the signal floors and the methodology behind the status assignment
• Orphaned resources — PVCs and load balancers left behind after a workload is deleted
• Right-sizing — for workloads that aren't abandoned but are clearly over-provisioned