Abandoned workloads

A team launched a service six months ago for a project that wound down. The pods still schedule, the cluster autoscaler still keeps the nodes warm, and the bill still arrives. Nobody on the on-call rotation remembers it exists. Abandoned Workloads is the page that surfaces it.

What "abandoned" means here

A workload is abandoned when it has been running for at least the idle threshold AND its measured activity sits below the network floor AND its resource utilization sits below the efficiency floor. All three signals together — not any one in isolation. A noisy network with low CPU still isn't abandoned; it's just inefficient. That's right-sizing territory, not this page.

Kubeadapt classifies every workload as one of three statuses:

The page summary counts Safe to Scale Down and Needs Review (which is Review first). The third bucket exists so you can see what was excluded.

The three signals

For every workload, Kubeadapt surfaces the underlying numbers so you can read the call and disagree with it where appropriate.

Network activity is captured from agent observation of ingress bytes, egress bytes, and connections per minute. A workload that has not accepted a connection in days but still has a Service in front of it is a classic abandoned-API signal. The page exposes:

• Ingress bytes — cumulative bytes received over the evaluation window
• Egress bytes — cumulative bytes sent over the same window
• Connections per minute — average new connections accepted per minute

Resource efficiency is CPU usage / requests and memory usage / requests, expressed as a percentage. A pod sitting at 0.5% CPU utilization for two weeks is doing very little. The page exposes:

• CPU usage % — CPU used / CPU requested, time-averaged
• Memory usage % — memory used / memory requested, time-averaged
• Total efficiency — the rolled-up efficiency score compared against the floor

Idle days is the number of consecutive days since the workload last crossed a meaningful activity threshold. Short idle windows produce Review first instead of Safe to scale down, because a weekend dip is not abandonment.

The exact floor values are scope-adapted at the cluster level — a small dev cluster tolerates lower absolute traffic before flagging than a 200-node production cluster. Open a row to see the floors that were applied to that workload.

When the page flags something you know is intentional

Some workloads are designed to be quiet. A nightly batch processor sits idle 23 hours a day. A disaster-recovery replica may be days behind on traffic. A debugging pod gets left running on purpose.

You have three ways to keep them out of the recommendations:

1. Dismiss the recommendation. Open the workload, choose Dismiss. The row drops off the active list. The workload still counts in inventory; Kubeadapt does not pretend it doesn't exist.
2. Label the workload as intentional. Add a label your team agrees on (for example kubeadapt.io/intentionally-idle=true) and the workload will continue to be evaluated, but you have a durable signal next to the row when reviewing.
3. Adjust expectations at the cluster level. If your cluster has many low-traffic workloads by design, work with your operator to tune the idle thresholds in the cluster's analysis policy. The defaults are calibrated for production-like clusters.

The distinction we care about is intentionally idle vs forgotten. A workload that the team meant to leave running but no longer monitors is still wasting money — Kubeadapt's job is to surface it. A workload that the team designed to be idle is not waste, and dismiss is the right action.

Acting on a recommendation

Kubeadapt does not scale workloads for you. The minimal path:

1. Open Clusters → [cluster] → Abandoned Workloads.
2. Filter the table to Safe to scale down.
3. Sort by monthly savings descending.
4. For each row at the top, confirm with the owning team that the workload is no longer needed. The Team, Department, and Owner fields on the row come from label-based cost attribution — they're the contact point.
5. Scale the workload to zero replicas (reversible) or delete it entirely (not reversible). Most teams scale to zero first and watch for complaints for a week before deleting.

After the change ships, the agent reports the new state on the next snapshot and the recommendation closes out automatically.

What the page shows

Per-cluster page at Clusters → [cluster] → Abandoned Workloads. Header tiles:

• Total Monthly Savings — sum of monthly savings potential across all flagged workloads.
• Total Abandoned — count of every workload Kubeadapt flagged.
• Safe to Scale Down — count of workloads in the Safe-to-scale-down status.
• Needs Review — count of workloads in the Review-first status.

The table lists workload name, namespace, controller type, replicas, status, last-active date, idle days, and monthly savings potential. Filter by namespace or status; search by name or namespace. Click a row to open the detail modal with the underlying network and efficiency numbers.

What's not here

• No automatic scale-down. Kubeadapt is read-only by design. The change happens through your CI/CD or kubectl.
• No fleet view. Recommendations are per-cluster today. To see abandoned workloads across all your clusters, walk the cluster list — the org-level Available Savings page rolls up the dollars, not the workloads.
• No cost-projection for partial scale-down. Scaling 4 replicas to 2 doesn't appear as a half-savings recommendation. Right-sizing handles "wrong size"; Abandoned Workloads handles "still running but not used".

Next steps

• Orphaned resources — the same idea applied to PVs and load balancers without owners.
• Right-sizing — for workloads that are still active but oversized.
• Cost attribution — once you know who owns the workload, you know who to ask before scaling it down.