The usage cap resets on a calendar month, not on a deploy
The hard-cap counter lived in memory for the life of the process, so a customer who capped out at 03:00 stayed locked out until we happened to deploy.
Metering moved onto the proxy, which means it advances on every request a customer’s plugin makes, and the cap became reachable by ordinary use. The counter it checked was a map cleared only by a restart. Nothing asserted when the lockout ended, which is how “it ends when we happen to deploy” stayed indistinguishable from a policy.
The counter is now keyed to a UTC calendar month and cleared when the month rolls. The roll runs at the top of the record call, before the cap check — rolling after it would refuse the first request of the new month and only then clear, which reads as the lockout outliving the month it belonged to. The read path rolls too, so the ops page cannot render last month’s total as this month’s. Reconciliation deliberately does not roll: an operator reconciling on the 1st must be told what was used, not “0 events” for a month that had usage.
Two of the new guard tests could not fail, both found by mutation rather than by reading. The year-boundary case drove December into January, where a month-keyed counter rolls anyway; rewritten to the same month a year apart, the only shape that separates the two implementations. The UTC case drove two times 29 minutes apart, which no offset from -12 to +14 can put a month boundary between — vacuous in every zone, and it looked killed only because the other tests died alongside it. Under the timezone CI actually runs, a regression to local time would have landed on main green.