Your dashboard is lying (but not the way you think)

When I started working in data, the first decision was always the grain of the fact table.

What decision are we supporting?
What pattern are we trying to see?
What is the simplest level of detail that still makes the insight possible?

Granularity was intentional.

In cloud FinOps, it often isn’t. We inherit it.

We take the CUR because that’s what exists. But two different dimensions are hidden inside that habit:

1. Granularity — the precision of the information (hourly, per resource, per tag).
2. Frequency — how often we receive updated data.

In AWS, cost granularity is hourly. Refresh might be eight hours. Guaranteed? Twenty-four.

Already, we are not in real time.

But here is what is fascinating: cloud vendors actually understand this better than we do.

In the AWS Cost and Usage Report, there is a column that explicitly indicates when a line item has been finalised. Until that date is populated, the data is provisional. It can change.

The vendor is telling us: this is not the bill yet.

And yet most dashboards ignore that signal.

They display mid-month numbers as if they were settled fact. They rarely indicate what is provisional and what is final. They almost never show how values evolved during the month.

Even structurally predictable items like support fees, Reserved Instance recurring charges, often appear as large spikes at the beginning of the month unless you deliberately smooth them. By default, you see a dramatic jump on day one. It looks alarming. It looks meaningful. It is simply billing mechanics.

Cloud vendors treat CUR data as financial data. And financial data follows a financial rhythm.

Before month end, what you are mostly seeing is usage—delayed by 24 hours and still subject to re-rating. After month end, mathematics are applied: discounts, enterprise agreements, credits, support calculations. That is when billing becomes billing.

In other words, the true financial signal is monthly.

Everything before that is directional.

And yet, culturally, we behave as if mid-month cost is a real-time operational metric.

When you see a dashboard, you feel in control.
When you see “we have spent 15 so far,” you feel anchored.

It creates psychological comfort.

The reality is that the number is provisional. It will shift when the financial layer is applied. And because we do not fully control that layer, we quietly ignore the instability.

The dashboard becomes reassurance.

FinOps sits between two tempos.

Engineering culture prefers immediacy.
Finance culture works in reconciliation cycles.

If we optimise only for refresh rate and decimal precision, we risk mistaking visibility for control.

Most FinOps impact does not come from watching numbers move hourly. It comes from shaping behaviour, designing guardrails, aligning incentives, and making trade-offs explicit.

In my own work, I now start from the outcome.

What behaviour must change?
What pattern needs to be visible?
What level of stability is required for trust?

Then I choose the largest possible grain and the slowest cadence that still supports that purpose.

Because FinOps is not about reproducing every technical signal the cloud exposes.
It is about making decisions under financial reality.

Mid-month data is useful.
But it is provisional.

Hourly precision is available.
But it is often unnecessary.

Billing is monthly.
Finance is slower than dashboards.

Real control comes from governance, not refresh rates.