System limits - Temporal Cloud
Temporal Cloud enforces a variety of limits to keep the service reliable, including rate limits (how often something may occur in a unit of time), resource limits (how many of a given resource may exist at any one time), and configuration limits (minimum or maximum values for a setting)
Every limit applies at a specific scope (level of the application):
- At the Temporal Cloud Account level
- At the Namespace level
- At the Nexus endpoint level
- Within the programming model itself
Account level
The following limits apply at the Temporal Cloud Account level (per account).
Users
- Scope: Account
- Default limit: 300 users
- How to increase: Contact support
Namespaces
- Scope: Account
- Default limit: 10 namespaces
- How to increase:
- Automatically increased as you start creating namespaces, up to a limit of 100.
- Contact support
Namespace level
The following limits apply at the Namespace level.
Actions per second
- Scope: Namespace
- Default limit: 400 actions per second (APS)
- How to increase:
- Automatically increases (and decreases) based on the last 7 days of APS usage. Will never go below the default limit.
- Contact support
See the Actions page for the list of actions.
Requests per second
- Scope: Namespace
- Default limit: 1600 requests per second (RPS)
- How to increase:
- Automatically increases (and decreases) based on the last 7 days of RPS usage. Will never go below the default limit.
- Contact support
See the glossary for more about RPS.
Operations per second
- Scope: Namespace
- Default limit: 3200 operations per second (OPS)
- How to increase:
- Automatically increases (and decreases) based on the last 7 days of OPS usage. Will never go below the default limit.
- Contact support
See the operations list for the list of operations.
Schedules rate limit
- Scope: Namespace
- Default limit: 10 schedule requests per second (RPS)
- How to increase: Contact support
To avoid throttling, don't schedule all your Workflow Executions to start at the same time (daily, weekly, monthly, etc.).
Every Temporal SDK supports jittering, which adds small random delays to Schedule specifications, helping to reduce load at any specific moment.
Set the jitter value to the largest delay you will permit before your Workflow Execution must begin.
This approach uniformly distributes the scheduled Workflow Execution launches through that period and reduces your Schedule Workflow Execution RPS load.
Visibility API Rate Limit
- Scope: Namespace
- Default limit: 30 Visibility API calls per second
- Not configurable
Calls subject to the Visibility API rate limit:
GetWorkerTaskReachabilityListSchedulesListBatchOperationsDescribeTaskQueueWithReachabilityListDeploymentsGetDeploymentReachability
Nexus Rate Limit
Nexus requests (such as starting a Nexus Operation or sending a Nexus completion callback) are counted as part of the overall Namespace RPS limit. If too many Nexus requests are sent at once, they may be throttled, along with other requests to the Namespace. Throttling limits the rate at which Nexus requests are processed, ensuring the RPS limit isn't exceeded.
You can request this limit be manually raised by opening a support ticket.
For the target Namespace of a Nexus Endpoint, even though there are no Action results for handling a Nexus Operation itself, the Nexus requests on a target Namespace do count towards the overall RPS limit for the Namespace as a whole.
Certificates
Temporal Cloud limits each Namespace to a total of 32 KB or 16 certificates, whichever is reached first.
Concurrent Task pollers
Temporal Cloud limits each Namespace to 20,000 concurrent Task pollers, regardless of whether they are Activity or Workflow Task pollers.
Each SDK offers a way to configure Workers for per-Worker maximum Activity and Workflow Task pollers. Those values do not affect the global Namespace limit.
Default Retention Period
The Retention Period is set per Namespace.
Temporal Cloud sets the default Retention Period to 30 days. This is configurable in the Temporal Web UI.
Navigate to your list of Namespaces, choose the Namespace you want to update, and select edit:
Choose your Namespace and select Edit
Update the Retention Period
You can set the Retention Period between 1 and 90 days.
Batch jobs
A Namespace can have just one Batch job running at a time.
Each batch job operates on a maximum of 50 Workflow Executions per second.
Number of Custom Search Attributes
There is a limit to the number of custom Search Attributes per attribute type per Namespace:
| Search Attribute type | Limit |
|---|---|
| Bool | 20 |
| Datetime | 20 |
| Double | 20 |
| Int | 20 |
| Keyword | 40 |
| KeywordList | 5 |
| Text | 5 |
Custom Search Attribute names
When creating custom Search Attributes in Temporal Cloud, the attribute names must adhere to the following constraints:
- Maximum characters: 64
- Allowed characters:
[a-zA-Z0-9.,:-_\/@ ].
For more information on custom Search Attributes see Custom Search Attributes limits.
Nexus Endpoint level
Nexus Endpoints limits
By default, each account is provisioned with 10 Nexus Endpoints. You can request further increases beyond the initial 10 Endpoint limit by opening a support ticket.
Programming model level
The following limits apply at the programming model level. See also: Self-hosted Temporal Service defaults.
Identifier length limit
Identifiers, such as Workflow Id, Workflow Type, and Task Queue names, are limited to a maximum length of 1,000 bytes. Note that Unicode characters may use multiple bytes.
Per message gRPC limit
Each gRPC message received has a limit of 4 MB. This limit applies to all gRPC endpoints across the Temporal Platform.
Event History transaction size limit
An Event History transaction encompasses a set of operations such as initiating a new Workflow, scheduling an Activity, processing a Signal, or starting a Child Workflow. These operations create Events that are then logged in the Event History. The transaction size limit restricts the total size of Events that can be accommodated within a single transaction.
The size limit for any given Event History transaction is 4 MB. This limit is non-configurable for Temporal Cloud.
Transaction Payload size limit
Blob size limit for Payloads, including Workflow context and each Workflow and Activity argument and return value:
- The max payload for a single request is 2 MB.
- The max size limit for any given Event History transaction is 4 MB.
This limit is non-configurable for Temporal Cloud.
The BlobSizeLimitError guide provides solutions for handling large payloads.
Per Workflow Execution concurrency limits
If a Workflow Execution has 2,000 incomplete Activities, Signals, Child Workflows, or external Workflow Cancellation requests, additional Commands of that type will fail to be applied to that Workflow Execution:
ScheduleActivityTaskSignalExternalWorkflowExecutionStartChildWorkflowExecutionRequestCancelExternalWorkflowExecution
For optimal performance, limit concurrent operations to 500 or fewer. This reduces Workflow's Event History size and decreases the loading time in the Web UI.
Per Workflow Execution Signal limit
A single Workflow Execution may receive up to 10,000 Signals. After that limit is reached, no more Signals will be processed for that Workflow Execution.
Per Workflow Execution Update limits
A single Workflow Execution can have a maximum of 10 in-flight Updates and 2000 total Updates in History.
Workflow Execution Event History limits
As a precautionary measure, a Workflow Execution's Event History is limited to 51,200 Events or 50 MB. It warns you after 10,240 Events or 10 MB. This limit applies to all Temporal Workflow Executions, whether on Temporal Cloud or other deployments. Read more about Temporal Workflow Execution limits on the Temporal Workflow documentation page.
Per Workflow Callback limits
A single Workflow Execution can have a maximum of 32 total Callbacks.
These limits may be exceeded when multiple Nexus callers attach to the same handler Workflow.
See the Nexus Encyclopedia entry for additional details.
Per Workflow Nexus Operation limits
A single Workflow Execution can have a maximum of 30 in-flight Nexus Operations.
See the Nexus Encyclopedia entry for additional details.
Nexus Operation request timeout
Less than 10 seconds is the maximum duration for a Nexus handler to process a single Nexus start or cancel request.
The timeout is measured from the calling History Service and the request must go through matching, so the available time for a handler to respond is often much less than 10 seconds. Handlers should observe the context deadline and ensure they don't exceed it. This includes fully processing a synchronous Nexus operation and starting an asynchronous Nexus operation, for example one that starts a Workflow.
If a Nexus handler doesn’t process a start or cancel request within 10 seconds, it will receive a context deadline exceeded error, and the caller will retry, with an exponential backoff, for the ScheduleToClose duration for the overall Nexus Operation. This has a default and maximum as defined below in Nexus Operation duration limits.
Nexus Operation duration limits
Each Nexus Operation has a maximum ScheduleToClose duration of 60 days. This is most applicable to asynchronous Nexus Operations completed with an asynchronous callback using a separate Nexus request from the handler back to the caller Namespace.
For enhanced security, you may sign completion callbacks with a single-use token in the future, and the 60 day maximum allows you to rotate the asymmetric encryption keys used for completion callback request signing.
While the caller of a Nexus Operation can configure the ScheduleToClose duration to be shorter than 60 days, the maximum duration can not extend beyond 60 days and capped by the server to 60 days.
Worker Versioning level
Max Worker deployments limits
The maximum number of worker deployments that the server allows to be registered in a single namespace. Defaults to 100.
Max versions in deployment limits
The maximum number of versions that the server allows to be registered in a single worker deployments at a given time. Note that unused versions will be deleted by the system automatically when this limit is reached. Defaults to 100.
Max Task Queues In Deployment Version limits
The maximum number of task queues that the server allows to be registered in a single worker Deployment Version. Defaults to 100.