Usage limits and what happens when you reach them

Current allowance source

The public Pricing page is the current plan and add-on catalogue. It shows prices, currency, billing interval, included capacity and each add-on's purchase range. The signed-in Billing page shows the entitlements and measured usage for the active workspace.

Byte allowances are displayed as MB or GB. Runtime compute is measured as Wasm execution fuel: work performed by a backend module consumes fuel, while browser frontend work and idle time do not. Preview CPU is measured in active milliseconds. Database queries, outbound requests, preview builds, resource operations and accepted telemetry events are counted as the named operation.

When a limit is reached

BlinkHost does not automatically purchase capacity or charge usage overages. Metered allowances use warning thresholds as usage approaches the limit. A hard-limited operation is rejected when accepting it would exceed the remaining allowance; saved project source and already purchased entitlement remain available. In-flight runtime work is bounded and stopped rather than allowed to create an unlimited bill.

Monthly counters reset at the start of the next usage month shown in Billing. A workspace owner can wait for that reset, reduce usage, buy a compatible add-on within the quantity shown in the catalogue, or change plan. Concurrency and resource-count limits are not monthly counters: finish or remove the relevant active resource, or increase the applicable capacity.

Telemetry above its event or byte allowance is not accepted, and BlinkHost does not bill an overage. Preview build, preview transfer, preview CPU, preview resource operations, database queries, runtime fuel and bandwidth likewise remain plan-governed. The UI should show the affected meter and a safe next action; contact billing@blinkhost.me if the displayed usage and a rejected operation disagree.

Customer impact by limit

Limit	What is rejected at the hard limit	What remains available
Project, environment or module count	Creating another governed resource	Existing saved projects and retained resources
Concurrent build or preview count	Starting another build or preview until one finishes	Existing source and completed deployments
Storage	An upload or deployment that would exceed remaining storage	Existing stored source, assets and retained artifacts
Monthly bandwidth	The affected delivery request once no allowance remains	Saved source and project configuration
Monthly runtime compute	Backend execution that cannot complete within remaining allowance	Static frontend content and saved module source, subject to their own limits
Outbound requests	A further outbound call from the affected module	Other permitted module work
Preview allowances	The preview operation that would exceed the relevant build, CPU, transfer or resource-operation meter	Production deployments and saved source
Database allowances	The new database operation or resource that exceeds the applicable count or monthly meter	Existing schema and project source; database availability remains subject to provider health
Telemetry allowance	Additional telemetry ingestion	Previously retained telemetry until its plan retention expires

The operation that crosses a hard limit fails instead of creating an automatic charge. A live application can therefore return an error for a request that depends on exhausted bandwidth, runtime, outbound-request or database capacity even though its source and retained deployment still exist. Billing identifies the affected meter; restoring service requires the next monthly reset, freeing count/concurrency capacity, a compatible add-on or a plan change.