CapacityLab
Console

Legal

Limits and rules

What CapacityLab applies today: per-Run limits, prices, retention periods and access rules. The Terms and the Privacy Policy take their current values from this page.

Version of .

Prices and credits

  • Credit pack. CapacityLab sells one credit pack: $19 of Load Run credit for $19, a one-time purchase without a subscription.
  • Load Run list price. A Load Run costs $1, plus $0.25 for each started minute of planned traffic and $0.50 for each started block of planned requests, at least one block.
  • Cost floor. When CapacityLab's upper-bound cost of a Load Run plus 30% exceeds its list price, the Load Run is priced at that cost floor instead, so no Load Run is sold below cost.
  • Request block. Planned requests are priced in started blocks of 10,000 requests.
  • Smoke price. A Smoke Load Run costs $0 and writes no ledger entry.
  • Smoke quota. An Account may start 10 Smoke Load Runs per UTC day. A Smoke that ends inconclusive because of CapacityLab does not count.
  • Welcome credit. A new Account receives $5 of welcome credit once; it does not expire and does not make the Account paid.

Load limits

  • Concurrent Load Runs per Account. An Account runs at most 100 Load Runs at a time, at every level and for Smoke; a finished Load Run counts until its generators are destroyed. A Load Run against a Target that accepts CapacityLab's generator OIDC identity runs alone among such Load Runs of its Account, because those generators carry the Account's fixed Machine names.
  • Generator capacity. Load generators come from a provider account with a limited number of machines, shared by all Accounts. Ready generators kept in each zone start a Load Run at once; other generators are created at about 24 a minute, and CapacityLab plans with 75% of that rate. When a Load Plan's generators do not fit under that limit, or would not be ready before its start deadline behind the generators already being created, Confirm refuses it as generator_capacity_unavailable, with a retry hint when it can estimate one, and charges nothing.
  • Load per hostname. All Load Runs that send load to one hostname at the same time, from any Account, together stay at or below the peak rate the target owner authorized with proof of control.
  • Load caps per Account level. A Load Run of a Free Account may reach 20 requests per second, 50 concurrent requests and 5 minutes of traffic; a Load Run of a paid Account 1,000 requests per second, 1,000 concurrent requests and 12 hours of traffic. A plan above a cap is refused, never shrunk.
  • Free check run limits. A free check run sends at most 5 requests per second, 1 minute of traffic and 300 requests.
  • Failed Smoke blocks paid Load Runs. If the latest Smoke of a Target and request set did not pass, a paid Load Run of the same Target and requests is refused until a later Smoke passes. A Smoke that CapacityLab itself could not judge (inconclusive, caused by CapacityLab) is skipped: it neither blocks nor keeps a block. Without any Smoke the agent is only warned. Smoke itself is never blocked.
  • Provider test windows. A hostname has an explicit traffic policy within your Account: unrestricted, windows-only or blocked. In windows-only mode the full preparation, traffic and drain must fit one confirmed finite calendar rule. Overlapping rules apply their smallest aggregate RPS limit; withdrawing a rule prohibits its intervals without allowing a broader rule to bypass the withdrawal. Revoking the last rule leaves windows-only mode. The policy survives recapture and port changes. Rules from the provider email remain proposals until an admin confirms them. The next fitting window is a hint, not a scheduled Run. The occurrence preview covers 90 days and at most 200 intervals; its horizon does not expire a rule. Each occurrence is at most 744 hours. Revoked or closed provider authority stops target traffic with customer attribution; a platform failure to renew permission retains platform attribution.
  • Generator zones. The member chooses the generator zone of every Load Run: Europe, United States or Asia. Each zone sends load from its own published addresses, and there is no fallback to another zone.

Access

  • Who can see Load Run results. Only live members of the Account can see its Load Run results and reports. An Account admin may publish one final Report on the public site with a README badge: the public page shows a copy without the Account's identifiers, prices, egress addresses or secrets, and without the Target's host unless the admin allows it; revoking it removes the page.
  • What an AI agent may do for each role. An admin can authorize an AI agent to manage applications, edit test designs, execute Load Runs and view the Account; a member can authorize it to view applications, edit test designs, execute Load Runs and view the Account.
  • Team seats. Every Account has the same member seat limit, the identity provider's organization membership limit (5 at the last check); the identity provider refuses an invitation beyond it.
  • Who can stop a Load Run. Any live member of the Account, admin or member, can stop its running Load Run, and so can an AI agent a member authorized to execute Load Runs.

Data retention

  • Account content. Workload revisions, confirmed Load Plans, Load Runs, their evidence, results and Targets are kept while the Account is open; closing the Account does not delete them.
  • Account secrets. An Account secret's value is stored encrypted (AES-256-GCM under a key used only for Account secrets, bound to its Account, secret and version) and is never shown back in Console or over MCP. It is decrypted only while a Load Run that pinned that version at Confirm has not ended: into that Load Run's generator Machines and for CapacityLab's check of its stored output. Before a generator writes any result, summary or error message it replaces the value and its encoded forms with the secret's name, and stored output that still contains it is deleted. A rotation stores a new version and erases every earlier version no running Load Run pins; a pinned version is erased when that Load Run ends. Deleting a secret, which is refused while a running Load Run uses it, and closing the Account erase every version. Erasure removes the encrypted value and its last characters; the version's number, author, creation time and token expiry stay in its history.
  • Action log. Events of the Account's action log are deleted 365 days after they occur.
  • Sign-in and refusal events. Sign-in, access-refusal and identity-change audit events are deleted 180 days after they occur.
  • Database backups. Database backups are kept for the backup retention period of the hosting provider.
  • Credentials. Closing the Account ends MCP access to it, deletes the closing member's MCP credentials and consents and erases the connected provider credentials; erasing a person's data deletes that person's MCP credentials and consents.
  • Identity. Your email, name and sign-in link are kept while you are a member of an open Account; when your last Account closes they are replaced by a pseudonym.
  • Credit ledger. Credit ledger entries (purchases, grants, charges and refunds) are kept, keyed by an opaque Account id rather than your email.
  • Operational logs and traces. Operational logs and traces are kept for the retention period of the hosting and tracing providers.
  • Payment webhooks. Payment webhook payloads are deleted 30 days after receipt unless the billing ledger still references the event; a referenced payload is kept while the reference exists.
  • Platform operator actions. Actions of CapacityLab's platform operators on the Account are kept in its audit log for 365 days.
  • Product telemetry. Product telemetry is kept for the retention period configured at the telemetry providers.
  • Raw load-test output. Raw load-test output is stored under a 30-day retention placement, or a 365-day one where it was set for the Account on request.
  • Support and data requests. Support conversations and data requests are kept by the support provider as evidence of handling.

Refunds

  • Automatic refunds. A charged Load Run is refunded in full, once, to the same Account when the generator failed to start, a deploy interrupted it, an operator stopped it, or it ran with intact data but CapacityLab could not produce a verdict. When the generator was unhealthy or run data was lost, it is refunded in full only if the Load Run ended without a verdict because of CapacityLab; when the affected seconds were left out and the verdict stands, the Result is kept and nothing is refunded for them. When a stop condition ends a Load Run early and no full refund applies, the unused traffic is refunded instead: the price of the minutes and request blocks the plan had not yet started when the stop condition triggered, scaled to the charged price; the launch fee is kept. A member's own stop and a target failure are not refunded.

Run deadlines

  • Finalization deadline. A Load Run's Result, or the refund of a Result CapacityLab could not deliver, is published at most 1 hour after its traffic ends.
  • Operator pause. In an incident the operator can pause new Load Runs: while the pause is on, Confirm refuses every new Load Run without charging, and Load Runs already admitted continue. Only the owner lifts the pause.