Build the panel and the mechanism shows itself. Unit cost is a ratio. The denominator, request count, you already emit, and it lands in telemetry in seconds. The numerator comes out of the vendor's billing pipeline, which is the same pipeline that produces the month-end loop the argument is trying to kill: bill arrives, finance reconciles, thread opens, an engineer spends a week in Cost Explorer reconstructing a number that has already been spent [6]. A ratio refreshes no faster than its slower input [15]. So the thing you hang next to p99 either updates on the invoice's cadence, which is the expense report with a division sign, or you meter usage against a rate card yourself and price it live. The second option is a project with an owner, not a dashboard config change.
The concession buried near the end of the post is the most useful engineering content in it. Clean cost per tenant is hard when tenants share a database and a NAT gateway, and the real work is tagging, cost-allocation keys, and a defensible split ratio for shared infrastructure [11]. The author's answer is that an 80 percent right cost per tenant on a dashboard beats a 100 percent right invoice nobody reads [12]. It holds because if your allocation is wrong by a factor that stays put, the level is wrong but the derivative survives [13]. A tenant whose cost per request climbs 40 percent still climbs 40 percent under a bad-but-stable key. Regression detection works. Pricing decisions do not, because they need the absolute level. That boundary is what is actually at stake when someone asks whether the number is real.
The sizing is where I would not follow the post. It puts the waste from the ownership gap at roughly a fifth to a third of cloud spend, described as what happens across the industry [2]. No study, sample, or method appears behind it; the only external authority cited anywhere is the FinOps Foundation, for the Unit Economics definition and the metric taxonomy [3][4][5]. Applied to a $2m annual bill, that range is $400,000 to $660,000 [14], which is the figure that gets a FinOps project funded. The method here carries a citation; the urgency figure carries none.
What the material does support is the diagnosis. A total in dollars cannot separate a bill that doubled with revenue from a bill that doubled because a debug log is streaming to an expensive tier; on the invoice those look identical [8]. Divide by requests and they stop looking identical: flat cost per request with a rising bill is growth, a flat bill with rising cost per request is a fault hiding behind a calm number [10]. Nobody reviews p99 once a month from a PDF, and cost is the one production signal still run that way [9]. That is a real argument for moving the metric onto the same wall and the same on-call rotation as latency [1].
In my context the order is forced by the denominator. Cost per request first, because requests are already counted. Cost per tenant after the allocation key exists and someone will defend it in a review.
