Your Kubernetes cluster is burning money. Find out where.
That’s the blunt message on the homepage of a new open-source project that has drawn attention from platform engineers tired of surprise cloud bills. Released on GitHub by Ozlem Tanrikulu, the tool called burn skips the usual overhead of agents, dashboards and complex YAML setups. Run one command. Get answers. The approach stands out in a market crowded with enterprise platforms that promise similar results but often require weeks of integration.
Engineers have complained for years about the gap between Kubernetes resource usage and actual dollars spent. Cloud provider bills arrive at the account level. Allocations to teams, namespaces or individual services remain guesswork. Burn attacks that problem directly. It queries the Kubernetes API for pods, persistent volume claims, services and ingresses. When available, it pulls real usage data from Prometheus. Then it matches those figures against current pricing from AWS, Azure or Google Cloud.
The result appears in clean tables. One view shows cost per pod. Another breaks out storage, load balancers and GPU resources. Spot instance readiness gets its own report, complete with discount percentages and interruption risk estimates. But the feature that has platform teams talking is the AI layer. Feed it a plain English question such as “why is argocd so expensive?” and it returns analysis plus ready-to-run kubectl commands. Rightsize this deployment. Switch that service to ClusterIP. Enable vertical pod autoscaling here.
“No agent to deploy. No dashboard to maintain. No YAML to configure. Just install and run,” the project README states. (GitHub – tanrikuluozlem/burn)
Installation options stay simple. Homebrew users type one command. Others download binaries, run the Docker image or install via Helm. The binary works on macOS, Linux and Windows. For teams that want recurring reports, a Slack bot mode turns burn into a live channel. Type /burn for the latest summary. Type /burn ask followed by a question to trigger the AI.
But does the industry need another cost tool? Recent surveys and analyses suggest the pain points have not gone away. A May 2026 report from Spendbase examined open-source cloud cost options and placed Kubernetes visibility near the top of persistent challenges. (Open Source Cloud Cost Optimization Tools (2026) – Spendbase) Commercial alternatives such as Kubecost, CAST AI and CloudZero offer deeper automation. Yet many organizations still run without any dedicated observability because the setup tax feels too high.
Burn tries to lower that barrier. It ships with an embedded pricing database updated weekly. If cloud credentials exist, it calls live pricing APIs for the most accurate rates. On-prem clusters accept custom hourly rates for CPU, memory and GPUs. The engine calculates costs at the resource level: dollars per CPU core per hour, dollars per GiB of RAM, storage fees, load balancer charges. It skips data transfer and load balancer unit costs, a known limitation noted in the documentation.
Time windows add flexibility. The default shows a point-in-time snapshot. Add –period 7d and the tool computes averages across the week. Filter to a single namespace for focused investigation. The spot readiness flag scans workloads against current instance types and returns a short list of candidates that could move to discounted capacity without excessive risk.
Recent industry coverage highlights how these capabilities address real operational friction. A LinkedIn post from late May 2026 showed engineers discussing rising Kubernetes spend and the difficulty of assigning responsibility. One commenter pointed to burn as a quick way to generate per-namespace breakdowns. Similar conversations appear in Reddit threads where DevOps teams describe budgets that grow faster than they can explain.
The AI component relies on Anthropic’s Claude. Users must supply an API key. Once connected, the model reviews cost data and usage patterns, then suggests concrete fixes. Early testers report the recommendations often match what a senior SRE might propose after hours of investigation. Still, the output remains advisory. Engineers must review and apply changes themselves.
Limitations exist. The tool does not track network egress fees or complex usage-based charges. Pricing for obscure instance types falls back to estimates. Teams running massive GPU fleets for AI training will need to tune the custom pricing flags carefully. And while the Slack integration feels native, it requires configuration of a Slack app, webhook URL and signing secret.
Even so, the project’s momentum feels genuine. As of early June 2026 the repository lists multiple releases, active issues and contributions focused on improving pricing accuracy and adding more cloud provider support. The author has positioned burn as a starting point rather than a full replacement for enterprise FinOps suites. Many organizations already layer multiple tools. One provides allocation. Another handles automated rightsizing. Burn could serve as the fast diagnostic layer that tells teams where to look first.
The Shift Toward Accessible FinOps
Cloud cost management has moved from quarterly budget reviews to continuous observation. Finance teams once owned the conversation. Now platform and engineering groups find themselves accountable for monthly spend. Tools that demand heavy configuration lose adoption. Those that deliver immediate value spread quickly inside Slack channels and internal wikis.
Burn fits the second category. Its zero-setup claim holds in practice for clusters that expose the standard Kubernetes APIs. Prometheus adds precision but remains optional. The combination of real-time pricing, usage metrics and natural language queries creates a feedback loop that feels closer to developer experience than traditional cost reporting. Ask a question. Receive an answer with commands attached. Apply the change. Watch the next report improve.
Analysts expect this pattern to grow. A recent guide to container cost management tools published in May 2026 listed more than a dozen commercial and open-source options. Most emphasize allocation accuracy and automation. Few emphasize speed of first insight. (11 Best Container Cost Management Tools in 2026 – Amnic)
Yet speed matters. Cloud bills compound daily. A misconfigured namespace running oversized pods can add thousands of dollars before anyone notices. A tool that surfaces the problem in minutes changes the economics of detection. It also changes culture. When every engineer can run burn analyze –namespace myteam and see their slice of the bill, conversations about resource efficiency become routine rather than exceptional.
Integration with existing workflows will decide how far burn travels. Some teams will schedule it as a daily CronJob that posts to Slack. Others will embed it in GitHub Actions or internal developer portals. The Helm chart and Docker image lower the bar for platform teams that prefer to run everything inside the cluster.
The project also reflects a broader trend. More infrastructure tools now ship with optional large language model features. The pattern appears in security scanners, log analyzers and now cost observers. The value comes not from replacing human judgment but from compressing the time between observation and action. A report that once took a FinOps specialist two days now appears in seconds. The follow-up question that once required another meeting now receives an answer with a kubectl snippet attached.
Of course, AI suggestions carry risk. A poorly tuned model could recommend changes that harm performance or availability. The burn documentation warns users to review output. Future updates may add confidence scores or simulation modes that preview the financial and operational impact before any command runs.
For now the project stays focused. Its author continues to iterate on pricing data, add support for more GPU types and refine the recommendation engine. The GitHub page carries the Apache 2.0 license, inviting forks and contributions. Early signals suggest the community has begun to respond.
Platform engineers who have spent years explaining why their cloud bill jumped 30 percent last month may find the tool useful. So might startups that cannot afford dedicated FinOps headcount. Even large organizations with mature cost platforms sometimes need a lightweight validator that runs independently of vendor contracts.
The name burn carries a double meaning. It evokes both the frustration of watching money disappear into infrastructure and the technical act of identifying exactly which workloads drive the highest charges. In an industry that prizes precision, that clarity arrives as a relief.
Teams that try the tool will likely start with a single cluster. They will run the basic analyze command, then add Prometheus, then experiment with the AI query feature. Some will discover idle workloads they can scale down immediately. Others will find load balancers attached to services that could use internal endpoints. A few will move qualifying workloads to spot instances and watch the next report reflect real savings.
The broader story is simpler. Visibility still drives behavior. When engineers see the dollar figure attached to their namespace, they treat resources with more care. When leaders receive weekly Slack summaries instead of monthly spreadsheets, cost discussions happen earlier. A small CLI that delivers both without ceremony may prove more influential than larger platforms that require committees to approve deployment.
Whether burn becomes a standard part of every Kubernetes toolbox remains to be seen. Its current traction suggests at least that the problem it solves still burns hot.
WebProNews is an iEntry Publication