Limits reference: every enforced number
Every numeric limit in one table: session lengths per plan, ttlSeconds bounds, act timeouts, workflow sizes and webhook delivery rates.
Last updated:
One page for every number the API enforces. Nothing here demands more than the ordinary key-in-the-Authorization-header authentication, and none of these values can be changed per request — the plan is what moves them.
The numbers
| Max session length | 1 hour on Free, 6 hours on Dev, 24 hours on Startup, 72 hours on Scale — enforced as `maxLifetimeAt`, which no keep-alive moves. |
|---|---|
| Reserved pool browsers | 0 on Free, 5 on Dev, 25 on Startup, 100 on Scale. |
| ttlSeconds | 30 seconds to 72 hours (259200 seconds) on session create and keep-alive. |
| act timeoutMs | 1 to 180 seconds; the default is 30 seconds. |
| Blocks per workflow | Up to 100 in one published version. |
| credentialIds per act | Up to 8 on a single act call. |
| Trigger minimum interval | 5 minutes between scheduled occurrences. |
| Webhook deliveries | 60 per minute per source IP on the delivery endpoint. |
| Audit log page | 5000 entries per page. |
| Audit export page | 50000 entries per page in the export bundle. |
As of 2026-09-02
How usage is metered
The billing clock on a session starts at readyAt — when the browser became usable, not when the request was admitted — and stops on every teardown path, a died container included. Holdings are different: profiles, stored credentials and reserved pool browsers are sampled once a day rather than metered as a flow.
Tip · Read your usage
`GET /v1/usage` returns the four metered dimensions over a window, per day, with open sessions and the included quota; the dashboard’s Verbrauch screen draws it. See the [usage guide](/docs/guides/usage-and-billing).