HashiCorp Nomad · Rate Limits
Nomad Rate Limits
The Nomad HTTP API does not enforce HTTP-level rate limits in the open-source distribution. Throughput is bound by Nomad server capacity (Raft commit, scheduler workers, RPC concurrency) and client-side ACL token limits. Nomad supports blocking queries and long-poll consistency modes that control how clients consume the API. Rate-limit-style protections are configured operator-side via ACL token hierarchies, namespaces, and Sentinel policies (Enterprise).
4 Limits
Rate LimitingWorkload OrchestrationDevOps
Limits
Nomad HTTP API server
bound by server CPU, memory, Raft commit rate
No per-second HTTP rate limit enforced; throughput is implementation-bounded.
Blocking queries per-request
5 minutes (default wait)
Clients can long-poll via index= and wait= parameters; `wait` defaults to 5 minutes, capped at 10 minutes.
Pagination per-request
100 (default)
Use `next_token` for cursor-based pagination on list endpoints.
ACL token enforcement token
token-policy-bound
ACL policies bound which endpoints / namespaces / nodes a token can reach.
Policies
Blocking queries / consistency modes
Use index= and wait= parameters for long-poll behavior; choose `stale` consistency for reads to spread load across followers and reduce leader pressure.
Pagination
Use `next_token` cursor pagination; do not enumerate all jobs / allocations in a single request.
ACL token scoping
Issue narrowly scoped ACL tokens per integration; revoke unused tokens promptly.
Sentinel governance (Enterprise)
In Enterprise, Sentinel policies can rate-limit operations like job submissions per namespace.
Namespaces (Enterprise)
Use namespaces to isolate teams and prevent noisy-neighbor scheduler pressure.