Home / Journal / OCI Cost Optimization / Building an OCI Cost Dashboard
OCI Cost Optimization

Building an OCI Cost Dashboard

A dashboard nobody acts on is decoration. A useful one answers who spent what, on which service, and whether it is normal, at a glance. The difference is not the charts. It is the attribution underneath and the questions the dashboard is built to answer.

Published Sep 13, 2024 · OCI Specialists · 9 min read
Building an OCI Cost Dashboard

Almost every organisation that worries about cloud cost builds a dashboard, and most of those dashboards end up ignored, because they display numbers without answering questions. A wall of charts showing total spend trending upward tells you that you are spending more, which you already knew, and gives you nothing to do about it. A dashboard that earns its place answers the questions a team actually has, which team drove this, on which service, is this normal or a change, and what should we look at first. The difference between decoration and a tool is not the visual polish, it is whether the data underneath is attributed well enough to answer those questions and whether the dashboard is designed around them. This guide covers how to build an OCI cost dashboard that drives decisions, starting from the foundation it depends on. It sits within the Oracle Cloud Cost Optimization pillar guide.

Attribution comes before visualisation

A dashboard can only show what the underlying data can distinguish, so the quality of a cost dashboard is set by the quality of the cost attribution before a single chart is drawn. If spend is not tagged to teams, services, and environments, the dashboard can only show the aggregate, and the aggregate cannot answer who or why. This is why building a dashboard starts not with a visualisation tool but with the tagging and account structure covered in Tagging Strategy for OCI Cost Allocation, because those are what let the dashboard break the total into the dimensions people care about. A beautiful dashboard on poorly attributed data is still decoration, while a plain dashboard on well attributed data is a tool. Get the attribution right first, and the dashboard becomes easy, because the data already knows how to be sliced.

Question the team hasWhat the dashboard needs
Who spent this?Spend attributed by team and owner
On what?Breakdown by service and environment
Is this normal?Trend against history and a baseline
What first?Largest movers and biggest absolute lines

Design around questions, not around data

The common failure is to put on the dashboard whatever data is easy to get, which produces a screen full of charts that each show something true and none of which prompt action. The better approach is to start from the questions the audience asks and build the smallest dashboard that answers them. An engineering lead wants to know which of their services moved and why. A finance partner wants the trend against budget and the forecast. An executive wants one number and whether it is on track. These are different dashboards, or at least different views, and trying to serve all of them on one screen serves none of them well. Designing around the question keeps the dashboard small and pointed, which is what makes it get used, because a screen that answers your question in five seconds beats one that buries it among twenty charts.

A dashboard full of true charts that prompt no action is decoration. A dashboard built around the questions people actually ask is a tool. The difference is design, not data volume.

Trend and baseline, not just the current number

A single current figure cannot tell you whether something is wrong, because wrong is defined relative to normal. The dashboard has to show spend against its own history so a viewer can see whether this month is in line with the pattern or a departure from it, which is the difference between a number and a signal. This is the same logic that underpins OCI Cost Anomaly Detection, brought into the visual layer, where the trend line and a sensible baseline let a human spot the change that a static total would hide. Showing the movement, the change from last period and the deviation from the expected, is what turns the dashboard from a report of where you are into an early indication of where you are going wrong.

Lead with the movers and the big lines

Attention is finite, so a useful dashboard directs it. The two things worth surfacing at the top are the largest absolute lines, because that is where the money is and therefore where optimisation pays most, and the largest movers, because a line that jumped is where something may have changed. A team that sees its biggest cost and its biggest change first knows where to look without scrolling, while a dashboard that lists everything equally forces the viewer to do the prioritising the dashboard should have done for them. The combination of biggest and most changed catches both the steady waste worth attacking and the sudden problem worth investigating, which together cover most of what a cost review needs to act on, a point developed in Quarterly OCI Cost Review Process.

  1. Fix attribution first, so spend can be sliced by team, service, and environment.
  2. Start from the audience's questions, not from the data that is easy to plot.
  3. Show trend and baseline, so a number becomes a signal.
  4. Lead with biggest lines and biggest movers, directing attention.
  5. Give each audience its own view rather than one crowded screen.

The dashboard is the surface, the practice is underneath

A dashboard does not save money on its own, it makes the spend visible so the practice around it can act, and a dashboard without that practice is a screen people glance at and forget. The value comes when the dashboard feeds the review cadence, the anomaly response, and the optimisation backlog, so what it surfaces turns into decisions. This is why the dashboard is best built as part of the wider cost operating model described in FinOps Operating Model for OCI rather than as a standalone artefact, because a dashboard that nobody is responsible for acting on reverts to decoration no matter how well it is built. The surface and the practice are two parts of one thing, and the dashboard only earns its keep when both exist.

How we build cost visibility

We treat the dashboard as the visible end of the cost practice, never as the whole of it, which means our OCI Cost Optimization work starts by getting the attribution right so the dashboard can answer real questions, then designs views around what each audience actually asks rather than around what is easy to plot. We surface trend and baseline so numbers become signals, lead with the biggest lines and biggest movers so attention lands where it pays, and wire the dashboard into the review and anomaly response so what it shows turns into action. Because our optimisation fee is paid only on verified savings, we build the dashboard to drive reductions that show up in the bill, not to look impressive in a meeting.

Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.