I've been consulting for Series B startups and kept running into the same wall: we needed to see where money was being wasted in the cluster, but installing tools like Kubecost or CastAI required a 3-month security review process because they install persistent agents/pods.
So I built a lightweight, client-side tool to do a "15-minute audit" without installing anything in the cluster.
How it works:
It runs locally using your existing kubectl context (read-only).
It grabs kubectl top metrics (usage) and compares them to deployments (requests/limits).
It calculates the cost gap using standard cloud pricing (AWS/GCP/Azure).
It prints the monthly waste total directly to your terminal.
Privacy: Pod names are hashed locally (SHA256) before any output. The analysis logic runs entirely on your machine (or client-side in the web viewer). No data leaves your laptop unless you explicitly choose to share it.
It's MIT licensed. I'd love feedback on the waste calculation logic—specifically, is a 20% safety buffer on memory requests too aggressive for production workloads?
Since this relies on kubectl top, isn't it just a point-in-time snapshot? How do you handle seasonality or nightly batch jobs that might spike resource usage when I'm not running the script?
OP here.
I've been consulting for Series B startups and kept running into the same wall: we needed to see where money was being wasted in the cluster, but installing tools like Kubecost or CastAI required a 3-month security review process because they install persistent agents/pods.
So I built a lightweight, client-side tool to do a "15-minute audit" without installing anything in the cluster.
How it works:
It runs locally using your existing kubectl context (read-only).
It grabs kubectl top metrics (usage) and compares them to deployments (requests/limits).
It calculates the cost gap using standard cloud pricing (AWS/GCP/Azure).
It prints the monthly waste total directly to your terminal.
Privacy: Pod names are hashed locally (SHA256) before any output. The analysis logic runs entirely on your machine (or client-side in the web viewer). No data leaves your laptop unless you explicitly choose to share it.
It's MIT licensed. I'd love feedback on the waste calculation logic—specifically, is a 20% safety buffer on memory requests too aggressive for production workloads?
Repo is here: https://github.com/WozzHQ/wozz
Since this relies on kubectl top, isn't it just a point-in-time snapshot? How do you handle seasonality or nightly batch jobs that might spike resource usage when I'm not running the script?
It is a snapshot. That's the trade off for being agentless. But for finding 10x over-provisioning a snapshot is usually enough to spot the pattern.
How exactly are you pulling the Kubernetes data without an in-cluster agent? Are you hitting the API server directly or relying on something else?
Looks useful
great to hear