Our takes

The trouble with dashboards that hide your real usage

A usage dashboard is supposed to answer a simple question at any moment: where do I stand right now. Plenty of dashboards answer a slightly different question instead: where did you stand as of the last time our billing system reconciled usage, which might be an hour ago, might be this morning, and during a traffic spike is exactly the gap that turns a manageable situation into a surprising overage or an unexpectedly exhausted free allowance.

We think the dashboard is the wrong place to put this information as the sole source of truth, not because dashboards are bad, but because a dashboard is inherently a step removed from the request that actually matters. The response to that specific request is the one place guaranteed to reflect your exact standing at that exact moment, because it is generated at the same time the request itself is being counted. That is why every response from My Geocode carries quota headers directly: your limit, what you have used, your remaining free allowance, your network's usage, remaining prepaid credit, and when the quota resets. You do not have to open a separate tab and hope it has caught up.

This matters most in exactly the situations where a lagging dashboard fails hardest: a sudden spike in traffic, a batch job that consumes a large chunk of allowance quickly, or a launch day where usage looks nothing like a normal day. A dashboard on a delay will keep showing a comfortable number well past the point where the real number has become urgent. Headers on the actual response you just received cannot lag in the same way, because they are not a separate reporting system trying to catch up. They are generated as part of answering the request itself.

A dashboard still has real value as a place to see trends over time, review history, or manage account details that do not change request by request. We are not arguing dashboards should not exist. We are arguing they should not be the only place, or the primary place, where a developer learns whether they are about to run out of allowance or credit. That information needs to be available at the moment it is actionable, which is the moment of the request, not sometime later when a dashboard's own refresh cycle gets around to reflecting it.

The deeper issue with a lagging dashboard is that it can create a false sense of security that is worse than having no visibility at all. A developer who checks a dashboard, sees a comfortable number, and proceeds with confidence has been actively misled by a tool that was supposed to prevent exactly that outcome. Real time information in the response itself avoids that trap entirely, because there is no separate system whose staleness needs to be accounted for before trusting the number.