Summary
Give us 30 minutes. Transform your cloud costs.
We will show you how to identify your savings opportunities and implement a simple FinOps governance model.
Why One Dashboard for Everyone Never Works
The foundational mistake is one we see with almost every client at the start: the dashboard. The single dashboard. The one that is supposed to satisfy the CFO, the Head of Platform, the team building the payment service, and the on-call engineer. A tool designed to speak to everyone and that, inevitably, ends up speaking to no one.
Because these people are not looking for the same thing. The CFO wants to know whether the quarterly budget is on track and where spending is heading. The engineer wants to understand why their cluster doubled in cost last night. Putting both on the same screen guarantees that each of them will have to dig, filter, and click—and a dashboard that requires digging to deliver its message is already a dashboard that has only half succeeded.
Our belief at Leonys
We don’t build a dashboard, we build a set of views.
Each one is designed for a specific audience, a specific question, and a specific review frequency. It takes more work upfront. It becomes infinitely more useful afterward.
What an executive should see in ten seconds
Let’s start at the top, because that’s where things most often go wrong. An executive view does not need granularity; it needs meaning. A CFO or VP opening their dashboard on a Monday morning should understand the situation before finishing their first sip of coffee.
Concretely: the total spend for the month, its trajectory compared to the approved budget, and the end-of-month forecast. If spending is exceeding expectations, by how much and since when. Three or four numbers, a chart, a variance. Not twenty-five technical metrics about instance types.
But, and this is where it gets interesting, a true executive view does not stop at the absolute amount. Spending more is not a problem in itself; spending more without getting anything in return is. That is why we always insist on surfacing at least one efficiency metric at this level: cost per active customer, cost per transaction, or cost relative to revenue. A cloud bill that increases by 30% while usage grows by 50% is not a cost overrun, it is good news. A dashboard that cannot communicate this nuance leaves your leadership team drawing the wrong conclusions.
The rule we set for ourselves is simple: if the executive has to click to understand, the view has failed. Everything else—the details, the investigation, the root cause analysis—belongs elsewhere, in the views that follow.
How much each product really costs, not each cloud account
Here lies the great misunderstanding. Your cloud provider presents the bill the way it sees it: by account, by technical service, by region. EC2 here, S3 there, network transfer somewhere else. Perfect for engineering. Terrible for managing a business.
Because no one in your company sells “S3”. You sell a product, a feature, a service to customers. And the question that really matters—the one that determines your margins and drives your decisions—is: how much does this product actually cost me? The product view is the exercise of translating between the language of the cloud and the language of the business.
Let’s be honest, this is the most difficult view to build. It requires allocation work that is far from straightforward: a solid tagging strategy, management of shared costs (the shared database, the Kubernetes cluster hosting twelve services, the common observability platform), and a deliberate decision about the portion of spending that cannot be attributed. That infamous “untagged” category that exists in every environment and that people tend to sweep under the rug.
Our position is clear: it is better to have an imperfect but explicit allocation than no allocation at all. If 15% of your costs remain unattributed, display it, name it, and make reducing it an objective. A product view that claims to be 100% accurate is lying; a product view that acknowledges its blind spots is a management tool.
Our position is clear
Better an imperfect but explicit allocation than no allocation at all. If 15% of your costs remain unattributed, display it, name it, and make reducing it an objective. A product view that claims to be 100% accurate is lying; a product view that acknowledges its blind spots is a management tool.
Giving each team a mirror of its own spending
Now let’s go one level deeper. Once you know how much each product costs, the people who create those costs need to see them. Not the CFO on their behalf. Them.
This is the principle behind showback, and it is more subtle than it seems. The goal is not to send an internal bill to make people feel guilty; it is to give each team a mirror. When a squad sees, week after week, what its stack is consuming, something shifts. The conversations change. “Do we really need this test environment running 24/7?” is not a question an engineer naturally asks; it is a question that visibility brings to the surface.
The team view therefore has a cultural value just as much as a technical one. It shifts cost ownership to where technical decisions are made, namely into the hands of developers and tech leads, rather than into a finance spreadsheet reviewed once a month. Cost becomes a property of the system in the same way as latency or availability.
One warning, though, because we’ve seen this go wrong. This view should never be used to publicly rank teams from the “biggest spenders” to the “most efficient.” The day your dashboard becomes a tool for naming and shaming, people stop optimizing and start playing with tags to make themselves look good. You gain flattering numbers and lose trust. The mirror, yes; the pillory, never.
Prod, staging, dev: why mixing everything together costs you money
This is one that is almost always overlooked, and it is often where the easy savings are hiding. Separate your environments in the dashboard. Production on one side, staging and development on the other.
Why? Because production costs are, to some extent, unavoidable: they support your customers, generate your revenue, and while they can be optimized, they cannot be cut carelessly. Non-production costs, on the other hand, are a completely different beast. This is where you find development instances left running over the weekend, staging environments sized like production “just in case,” and test databases left running throughout an entire team’s vacation.
When you mix the two into a single trend line, that waste becomes invisible. It gets lost in the noise. Separate them, and suddenly a truth becomes obvious: your non-production environments may account for 30, 40% of the bill with zero revenue attached to them. It is uncomfortable to look at. It is also the fastest cost-saving lever most organizations can pull, long before negotiating Savings Plans or launching rightsizing initiatives.
This view deserves its own alerts as well, because the rules are not the same: a cost spike in production may be perfectly legitimate (a traffic surge, a successful launch); the same spike in a development environment is almost always a problem.
When the dashboard should alert you, and when it should stay silent
Let’s talk about alerting, because a purely passive dashboard requires you to look at it to know that something is happening—which, as we’ve already said, never happens often enough. Good alerts come to you. The key, however, is to distinguish between two categories that people constantly confuse.
There is the budget alert. Predictable, calm, almost administrative: you set a budget, and you are notified when you reach 80% and then 100% of the forecast. It is useful for governance, it supports financial discussions, and it does not wake anyone up. You know in advance that it will eventually trigger; the only question is when.
And then there is anomaly detection. That is a different beast altogether. Here, you are not comparing against a fixed threshold but against expected behavior—the spend of today compared to what previous days would have predicted. This is the alert that catches the S3 bucket suddenly costing ten times its usual amount because a script is stuck in a loop, the poorly written query scanning terabytes of data, or the resource an attacker has been running in your account. These things do not care about monthly budgets; they happen at three in the morning, and they hurt.
The real challenge with alerting is not creating alerts, it is making them sustainable.
The deadly enemy is called alert fatigue: beyond a certain volume of notifications, the human brain starts ignoring them altogether, and the alert that truly mattered gets lost in the noise.
We always prefer three relevant alerts routed to the right team over thirty generic alerts flooding a Slack channel that everyone has eventually muted. Tuning thresholds, routing alerts to the appropriate owner, and prioritizing severity levels: that is where the difference lies between a system that protects you and one that gets disabled after a month.
A dashboard that nobody looks at is already dead
We come back to the concern we started with, and it needs to be addressed head-on, because it determines everything. The most beautifully designed set of views in the world is useless without the ritual that brings it to life.
A dashboard is not a deliverable, it is a tool for recurring conversations. And those conversations deserve a deliberate cadence. At a shorter interval—every week, or every two weeks—an operational review where teams look at anomalies, short-term trends, and ongoing optimization initiatives. At a broader interval—the month, the quarter—a governance review where spending is measured against objectives, where efficiency and margins are discussed, and where leadership makes the necessary trade-offs.
What creates value in these meetings is not the fact that people look at the numbers. It is the fact that they leave with a decision. A FinOps review that ends without any action being agreed upon, without any owner being assigned, is just another meeting in already overcrowded calendars. The discipline can be summed up in one sentence: every view in your dashboard should be tied to a meeting, and every meeting should result in a commitment.
It may sound provocative, but we stand by it: show us your review cadence, and we will tell you whether your FinOps practice is alive or merely decorative. The tool comes afterwards.
Questions we get asked all the time
What tool should you choose to build all of this?
The answer may disappoint you: it matters less than you think. We are constantly asked whether the right choice is Cloudability, CloudHealth, Kubecost for Kubernetes, or building a custom stack on top of a data warehouse—and the truth is that we have seen excellent dashboards built using native cloud tools (Cost Explorer, Budgets, built-in anomaly detection) and complete disasters running on the most expensive platforms on the market.
The tool does not create discipline; it amplifies it. Our practical advice: start with native tools—you will get much further than you think—and only invest in a third-party platform when a real limitation starts causing pain (multi-cloud environments to reconcile, detailed Kubernetes cost allocation, or a level of granularity that native tools cannot provide). Buying the tool before defining the operating model is putting the cart before the horse.
How many views do you actually need?
Not a number. A logic. You need as many views as you have distinct audiences making distinct decisions. If your leadership team, your product teams, and your on-call engineers are looking at three different questions, then you need three views—at a minimum.
The trap is not having too few views—it is the opposite: proliferation. The view that gets created “just in case,” the one that someone requested once and that nobody ever opens again. A good practice is to regularly remove views that are no longer being used, just as you shut down forgotten development instances. A dashboard needs to be maintained like a garden; it should not be allowed to accumulate.
At its core, a FinOps dashboard is nothing more than a revealer. It does not reduce your costs on its own—it makes visible the decisions you were avoiding simply because you could not see them. The day every number displayed has an owner, a meeting, and a possible action attached to it, you no longer have a dashboard. You have an organization that knows what it is spending and why. That is rare. And that is exactly where everything begins.
Want to see what this looks like in practice?
We offer a demo of a Leonys dashboard, along with personalized recommendations based on your own environment. Let’s talk.
FAQ
An effective FinOps dashboard must be tailored to its audience. Executives need budget visibility and forecasting, while technical teams need insights into costs by product, service, or environment. The goal is to turn cloud data into actionable decisions rather than simply displaying metrics.
The most commonly used FinOps KPIs include monthly cloud spend, end-of-month forecasts, cost allocation coverage, product-level costs, team-level costs, unit costs, and realized savings. These metrics should be aligned with the organization's financial and operational objectives.
A cloud dashboard typically displays technical metrics and costs by cloud service. A FinOps dashboard goes further by linking spending to teams, products, business objectives, and governance decisions in order to drive value creation.
