System limits - Temporal Cloud
This page addresses the limits of the Temporal Cloud system. Reach out to your account team should you have any questions about these limits.
These limits fall into the following three main categories:
- At the Temporal Cloud Account level
- At the Namespace level
- Within the programming model itself
Account level
The following aspects apply at the Temporal Cloud Account level (per account).
Users
How many users can I add?
By default, 300 users across all Namespaces.
Namespaces
How many namespaces can I create?
By default, each account is provisioned with ten Namespaces. As you start using Namespaces by scheduling Workflows, Temporal Cloud automatically raises your allowance. This automatic adjustment happens whenever all your Namespaces are in use, up to a maximum of 100 Namespaces. You can request further increases beyond the 100 Namespace limit by opening a support ticket.
Retained Prometheus endpoint data
How much metrics data does the Prometheus endpoint retain?
The Prometheus endpoint retains 30 days of data.
Supported operators in List Filters
Which operators aren't supported in Temporal Cloud?
The ORDER BY operator isn't supported in List Filters in Temporal Cloud.
This means that custom ordering of Workflows with Temporal Cloud Visibility isn't possible. Lists of Workflows are still ordered by a default ordering rule, but be aware that this rule might change.
Namespace level
The following aspects apply at the Namespace level (per Namespace).
Throughput
What is the limit of Actions per second?
Each Namespace has a rate limit, which is measured in Actions per second (APS). A Namespace may be throttled when its throughput becomes too high. Throttling means limiting the rate at which Actions are performed to prevent the Namespace from exceeding its APS limit.
A Namespace's default limit is set at 400 APS and automatically adjusts based on recent usage (over the prior 7 days). Your throughput limit will never fall below this default value. You can request this limit be manually raised by opening a support ticket.
Schedules rate limit
Each Namespace has a default Schedule rate limit of 10 requests per second (RPS). If too many Schedules trigger at once, they may be throttled. Throttling limits the rate at which Schedules create new Workflow Executions, ensuring the Namespace does not exceed its RPS limit.
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.
If you need a higher Schedule RPS limit, open a support ticket.
Certificates
What are the certificate limits?
Temporal Cloud limits each Namespace to a total of 32 KB or 16 certificates, whichever is reached first.
Concurrent Task pollers
Is there a limit to concurrent Task pollers?
Temporal Cloud limits each Namespace to 5,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
What is the 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
How many batch jobs can run at a time?
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
How many custom Search Attributes are allowed per Namespace?
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
What constraints are there for Custom Search Attribute names in Temporal Cloud?
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.
Visibility API Rate Limit
What is the rate limit for requests to the Visibility APIs?
The rate limit for requests to the Visibility APIs varies, and may be as low as 30 requests per second. This limit is not configurable.
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.
Nexus Endpoint level
Nexus Endpoints limits
How many Nexus Endpoints can you create?
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 aspects apply at the programming model level. See also: Self-hosted Temporal Service defaults.
Identifier length limit
What is the maximum length for identifiers?
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
What is the gRPC limit for each message received?
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
What is the size limit for an Event History transaction?
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.
What is the blob size limit for a transaction?
- 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
How many incomplete concurrent operations can a Workflow Execution have?
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
What is the limit on the total number of Signals received per Workflow Execution?
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
What is the maximum number of Updates for a single Workflow Execution?
A single Workflow Execution can have a maximum of 10 in-flight Updates and 2000 total Updates in History.
Workflow Execution Event History limits
What are the limits that apply to the Workflow Execution's Event History?
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 Nexus Operation limits
What is the maximum number of Nexus Operations that can be started from a single Workflow Execution?
A single Workflow Execution can have a maximum of 30 in-flight Nexus Operations and 30 total Nexus Operations (as Public Preview does not remove completed Nexus Operations from mutable state). After the Workflow Execution reaches that limit, it won't process any further Nexus Operations.
See the Nexus Encyclopedia entry for additional details.
Nexus Operation request timeout
What is the context deadline timeout for a Nexus handler to process a Nexus start or cancel request?
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.