Usage — admin

Who opens it: an organizer watching an event fill up, or an owner deciding whether to upgrade. Anyone who may read reports can see it — how full an event is, is an operations question, not a money one.

What they came to do: find out how close an event is to its limit, and what going past it would cost.

True when they leave: they know the number, the limit, and either what the overage would come to or that registration will stop.

Decisions already made

• It reads the settled figures only (usage_meters), never the live counters. A counter lives in Redis and can be flushed; the rollup recomputes from rows and overwrites it. So a number here can be a few hours old — which is the right trade for one that never contradicts the invoice.
• The projection uses the same arithmetic as the real charge. An organizer deciding whether to upgrade should be reading the number they would actually be billed, not an estimate with a different rounding rule.
• The limit shown is the one the event was sold at — the cap at publish, or the higher cap if the event was upgraded — not today's plan, because that is what the bill will use.
• On a plan that blocks at the cap it does not quote a price. Free stops registration instead of charging, so the page says that, and says upgrading reopens it.
• A person counts when they are active on a confirmed registration — the same population the cap is enforced against. The number that bills and the number that blocks are never allowed to disagree.

Open questions

• Nothing here shows emails or SMS sent, because nothing is billed on them yet (emails is fair-use monitoring and sms lands in week 18). The section is built to take them.
• No history: it shows the current peak per event, not a curve over time. A curve would answer "when did it spike", which nobody has asked for yet.
• A closed event shows what was charged, but the charge itself lives on the Billing page. Two places, one number.