Windmill · Rate Limits

Windmill Dev Rate Limits

Windmill does not publish fixed numeric per-endpoint request-rate limits for its REST API. On self-hosted Community Edition, throughput is bounded only by your own infrastructure and by how many workers you run - each worker pulls and executes jobs from the shared Postgres-backed queue, so overall execution concurrency scales with the size of your worker fleet. On Windmill Cloud and Enterprise, effective throughput is governed by your provisioned Compute Units (worker capacity) and seat entitlements rather than by a per-minute API cap. Application-level flow control is expressed through per-script/per-flow concurrency limits and named concurrency groups, plus worker group tags that route and cap specific workloads.

Windmill Dev Rate Limits is the machine-readable rate-limit profile for Windmill on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 6 rate-limit definitions, measuring requests, jobs, worker_capacity, concurrent_executions, and various.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Developer Platform, Workflows, Job Orchestration, Rate Limiting, and Quotas.

6 Limits Throttle: 429
Developer PlatformWorkflowsJob OrchestrationRate LimitingQuotas

Limits

REST API Requests account
requests
not published
No fixed numeric request-rate limit is documented for the Windmill REST API.
Self-Hosted Execution Throughput deployment
jobs
worker-fleet-bound
Concurrency scales with the number and size of workers you run; bounded by your own hardware.
Compute Units account
worker_capacity
per plan
On Cloud/Enterprise, execution capacity is provisioned in Compute Units (about 2 worker-GB-month each).
Per-Script / Per-Flow Concurrency runnable
concurrent_executions
configurable
Each script or flow can declare a maximum number of concurrent executions within a time window.
Concurrency Groups group
concurrent_executions
configurable
Named concurrency groups cap combined concurrency across multiple runnables that share the group.
Community Free Tier Caps instance
various
10 SSO users / 3 workspaces / 4 groups / 100 emails per day
Structural caps on the free Community Edition, not request-rate limits.

Policies

Queue Backpressure
Jobs are enqueued in a Postgres-backed queue and pulled by available workers; when workers are saturated, jobs wait in the queue rather than being dropped.
Concurrency Limits
Per-runnable and per-group concurrency limits smooth spikes and protect downstream systems from overload.
Retries and Timeouts
Scripts and flow steps support configurable retries with backoff and per-job timeouts to bound runaway executions.
Backoff Strategy
API clients should implement exponential backoff with jitter and honor Retry-After on any 429 response.

Sources