Freezing new work before revoking the leaked key keeps the refusals explainable

A cap sits where the spend is authorized. The testable claim in the post is narrow. After the cap is reached, new billable work for the affected identity is rejected, and work already accepted is either completed or recorded as in-flight according to the provider contract ^[2]. A budget alert cannot make that claim, because it is a notification channel, and notifications can be delayed, deduplicated, or missed during an incident ^[3]. The author's rule for choosing is the requirement's own wording: cap when it says do not authorize more spend, alert when it says wake someone at 60%, both in production with separate owners and tests ^[21].

The sample gate is small on purpose. GateState is open, frozen or released; admit() returns false whenever the state is not open, and the event it pushes carries at, workloadId, keyVersion, state and reason ^[11][12]. It records the key version, not the key value ^[13]. The post calls the gate deliberately incomplete, and puts the durable ledger in a shared store and the cap in the account or billing control that actually authorizes usage ^[13]. The post states the reason plainly: concurrent processes cannot share an in-memory counter safely, so the local decision is a fast brake while the account control takes effect ^[10].

Then the failure chain a tabletop misses. The alert fires at 60%, an operator clicks freeze, one Node.js process receives the new flag, and a second process keeps an old in-memory value while its queue consumer retries ^[17]. Usage arrives from the provider in five-minute aggregates, so the dashboard looks quiet until the final batch lands ^[18]. Verification therefore trails the freeze by at least one aggregation window ^[22]. So every queue message carries a workload ID and admission timestamp, the freeze version is persisted in shared storage, and each consumer emits its observed version on a heartbeat ^[19]. At review, those records are sorted by event time against the provider's usage window ^[20].

"I once saw a dashboard turn green because the alert worker had acknowledged a message," the author wrote ^[14]. The API workers were still accepting traffic, and an acknowledgement is not enforcement ^[15]. The instrumentation asked for is three signals with different failure modes: a metric for rejected admissions, a counter for accepted work after the freeze timestamp, and a log field for the control-plane decision ID ^[16].

The order of the steps in the stop path matters: detect the signal, freeze new work, revoke or quarantine the exposed key, observe the cap decision, release only after review ^[8]. Revoke first and queued requests fail without a useful reason. Freeze first and the ledger can explain why work was refused ^[9].

Identity comes before the threshold. A key shared by checkout, reconciliation and a test job makes the ledger ambiguous, so each deploy target and environment needs a stable account or project identifier, stored with request metadata instead of with the secret value ^[5][6]. In my view that split is the expensive part of adopting any of this, and it has to land before the drill. A ceiling drawn around one shared key is either too high to bound the incident or low enough to stop checkout when the test job runs hot. The post also cites OWASP's secrets guidance for least privilege, rotation and keeping secrets out of logs ^[7]. It is a tabletop design; it does not report a measured interval between the cap trip and the first rejected request ^[23].