Every engineer who's ever gotten a 3am page has the same instinct: overprovision everything, and never speak of it again. Give the pod double the memory it probably needs. Reserve the bigger node. Keep warm capacity standing by for a spike that might never come. Nobody gets paged for wasting money. Everybody gets paged for downtime.
That instinct is completely rational, and it is also, according to Datadog's own cost research, why 83% of container costs go toward resources nobody is using, more than half of that from clusters that are simply oversized for the job. Kubernetes promised elastic, on-demand scaling. What most of us actually run is a fleet of "just in case" boxes we're too scared to touch.
DevZero, founded by a couple of ex-Uber engineers, just launched a platform aimed squarely at that fear. It profiles your clusters, nodes, and individual workloads to build a statistical model of what they actually need, then rightsizes CPU, memory, and GPU allocation live, across a genuinely absurd matrix: 3,000-plus instance types, 69,000 price points, 23 GPU types, 80 regions. The company claims the average client was overspending on compute by 53% before adopting it, and that customers typically cut their bill by 30 to 60% after.
Sounds like every vendor pitch you've ever skimmed past, doesn't it? Round numbers, a savings percentage generous enough to make the case for you. Fair reaction. Take those specific percentages with the grain of salt they deserve: they're the vendor's own numbers, not independently audited, and every optimization vendor in this space quotes a version of the same impressive range. That's not a knock on DevZero specifically. It's just how vendor math works, and you should read every cost-savings headline in this industry the same way.
Here's the part that's actually interesting, and it's not the percentage. It's the mechanism.
The reason teams don't rightsize aggressively isn't ignorance, it's fear. You know your staging environment is oversized. You leave it that way because if you're wrong about how much headroom you actually need, the fix is a restart, and a restart at the wrong moment is an incident. DevZero's answer to that fear is checkpoint-restore: a way to live-migrate a running workload to a differently sized instance without stopping it first. One early customer described DevZero moving their workloads mid-availability-zone-outage without a single restart or a human touching anything.
If that holds up under your own testing, and I'd test it hard before trusting it in prod, it's a genuinely different answer to an old problem. Every rightsizing tool up to this point has asked you to trust its recommendation. This one is asking you to trust its execution, live, on workloads you already have running. That's a much bigger ask, and it should be. Autonomous infrastructure control that's wrong once, at 2am, on the wrong pod, is a very bad night.
So don't skip the boring part. Whatever you evaluate here, DevZero or one of the half dozen tools chasing the same problem, start on the workloads you'd be least sad to lose for an hour. Watch what it actually does before you let it anywhere near the thing that pages you at 3am. Confidence in a rightsizing engine isn't something a vendor's number gives you. It's something you earn one blast radius at a time.
Source: Cloud Native Now, "DevZero Launches Automation Platform to Dynamically Rightsize Kubernetes Clusters," and DevZero's official launch announcement (June 9, 2026).
