wozz

ent kubecontext to compare reserved requests vs. actual live usage (kubectl top). This helps find the "Sleep Insurance" gap—where devs request 4GB RAM just to be safe, but the app only uses 200MB. Implementation Details Stack: TypeScript/Node.js. Math: Instead of querying AWS Cost APIs (which requires sensitive creds and is slow), it uses a configurable Blended Rate (e.g., $0.04/GB/hr) to estimate costs deterministically. Privacy: It runs 100% locally or in your runner. No manifests or secrets are sent to any external server. Repo https://github.com/WozzHQ/wozz Feedback I’m currently using a static Blended Rate for the cost math to keep the tool fast and stateless. I’m curious if this approximation is accurate enough for your team's guardrails, or if you strictly require real-time Spot Instance pricing to trust a tool like this?

m the buffer with headroom etc.. This is how bad metrics wreck corporate cultures, the ones in this case encourage overspending. If I use all that ram I will never hit the "top_offender" list[3] even if I cause 100 extra nodes to be launched. Without context, and far more complicated analytics "request - actual usage (MiB)" is meaningless, and trivial to game. What incentive except making sure that your pods request ~= RES 24x7x356 ~= OOM_KILL limits/2, to avoid being in the "top_offender" does this metric accomplish? Once your skip's-skip's-skip sees some consultant labeled you as a "top_offender" despite your transient memory needs etc... how do you work that through? How do you "prove" that against a team gaming the metric? Also as a developer you don't have control over the clusters placement decisions, nor typically directly choosing the machine types. So blaming the platform user on the platform teams' inappropriate choice of instance types, while shutting down many chances of collaboration by blaming the platform user typically also isn't a very productive path. Minimizing cloud spend is a very challenging problem, which typically depends on collaboration more than anything else. The point is that these scripts are not providing a valid metric, and absolutely presenting that metric in a hostile way. It could be changed to help a discovery process, but absolutely will not in the current form. [0] https://github.com/WozzHQ/wozz/blob/main/scripts/wozz-audit.... [1] https://github.com/google/cadvisor/blob/master/cmd/internal/... [2] https://github.com/WozzHQ/wozz/blob/main/scripts/wozz-audit.... [3] https://github.com/WozzHQ/wozz/blob/main/scripts/wozz-audit....

law and you will teach your dev team to not just request, but allocate memory and don't free it so that they can fit inside this invalid metric's assumptions. It is going to work against the more reasonable goals of having developers set their limits as low as possible without negative effects, while also protecting the node and pod from memory leaks, while still gaining the advantages of over-provisioning, which is where the big gains are to be made. [0] https://github.com/WozzHQ/wozz/blob/main/scripts/wozz-audit.... [1] https://github.com/WozzHQ/wozz/blob/main/scripts/wozz-audit.... [2] https://kubernetes.io/docs/concepts/configuration/manage-res...

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

/main/scripts/w... | bash ``` Or clone first if you don't trust curl | bash: ```bash git clone https://github.com/WozzHQ/wozz.git cd wozz bash scripts/wozz-audit.sh ``` Most common finding: "AI-generated YAML" with overly generous limits. ChatGPT/Copilot tends to suggest 8GB when 1GB would work. I'm doing free analysis for the first 50 clusters (email output to audit@wozz.io). Would love feedback on: 1. Is the anonymization approach sufficient for your security team? 2. What other cost patterns should I detect? 3. Would a GitHub Action version be useful? Code: https://github.com/WozzHQ/wozz Website: https://wozz.io Happy to answer questions!