Comparisons
Why Grafana dashboards can't bill anyone
Grafana is excellent at visualising data you already model. Billing needs the four things it deliberately does not do.
This is not an argument against Grafana. It is very good at what it is for, most engineering teams should have one, and if you are watching latency and error rates you should stop reading here and go back to it.
It is an argument about a specific mistake: reaching for a dashboard tool when the actual problem is billing. It happens because the first symptom of a billing problem is usually 'we cannot see our usage', and a dashboard tool is the obvious answer to not being able to see something.
What a dashboard tool assumes
Grafana assumes you have already done the hard part. It connects to a data source you built, queries a schema you designed, and draws what you ask for. That is a clean separation of concerns and it is why it works with almost anything.
For billing, the hard part is everything on the other side of that boundary. The data source, the schema, the pipeline that keeps it fed, and the logic that turns quantities into money — none of which a visualisation layer has an opinion about.
The four things it does not do
It cannot rate
A panel can plot 372 seconds. It cannot tell you that those seconds cost £0.1562, because that requires a tariff with increments, minimums and longest-prefix matching, and a rule about which version of that tariff was live when the call happened. You would have to compute the amount before Grafana saw it — at which point the billing engine already exists and Grafana is drawing its output.
It has no concept of a period
A time range on a dashboard is not a statement period. A statement period is a fixed, closed, timezone-aware window that produces the same total every time it is asked, including across clock changes. A dashboard is deliberately the opposite: it shows you what is true now, over whatever window you drag to.
It cannot audit what you are charged
Reconciliation means comparing an external document against your internal record, line by line, and categorising every difference. It is not a visualisation problem. Nothing about plotting a series helps you decide whether a carrier's rate for prefix 4479 matches the rate you agreed.
It does not drill down to arithmetic
You can drill from a panel to a narrower query. You cannot drill from a figure to the specific event that produced it and then to the calculation that priced it — because the calculation was never recorded. That trace is what makes a charge defensible, and it has to be stored at rating time.
The costs that do not appear in the comparison
Self-hosting is real work: upgrades, access control, backups, and someone who knows how it is configured. Grafana Cloud removes that and introduces a bill that moves with what you monitor — it is sold per active series, per log and trace volume, and per active user.
Neither is unreasonable for a monitoring tool. Both are awkward for billing, where you want a predictable monthly cost and where the volume of things you are metering is precisely what you want to grow.
What to use instead
For billing specifically, you want something that owns the whole path: metering, a rating engine with versioned plans, statements, and an audit trail per charge. Dashboards should be an output of that system rather than a separate tool pointed at it, because then every figure on them already knows what it means.
Keep the dashboard tool for infrastructure. The two jobs look similar on a screen and are completely different underneath, and trying to make one do the other is how teams end up maintaining a billing engine nobody planned to build.