A lock flag on the account row, checked at the top of the data proxy on every request and cached briefly. Locked accounts get HTTP 402 with a machine-readable code the client turns into the lock screen. Routing deliberately still resolves a locked account's subdomain so the tenant can get to the screen that lets them fix it.
Also called: account locked pending payment · billing lock · past due · unlock by paying
- 1orgIsBillingLocked() reads the account's billing status, cached 30 seconds per instance.
- 2A locked account gets a 402 with code 'billing_locked' from every data-proxy call.
- 3The client surfaces the lock state via the bootstrap endpoint's billing_locked flag.
- 4Subdomain resolution treats a locked-but-suspended account as resolvable on purpose.
- 5Unlocking is a status change, and the short cache means it takes effect within seconds.
The rule is recorded in the middleware resolver as a one-line judgement, Keith 08-18: 'A billing lock is a suspension the tenant can lift by paying — the subdomain must still resolve so they reach the lock screen.' Without that carve-out the account would stop resolving entirely and the customer would have no route to the page that takes their payment. The proxy comment states the scope of the lock plainly: 'the whole data proxy is closed until they pay.'
- A hard suspension for non-payment leaves the customer with no route to pay.
- A generic 403 gives the client nothing specific to render.
- Checking billing state per request would hammer the database.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →