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

Hard and soft limits

Temporal Cloud enforces two types of limits:

• Hard limits are fixed and cannot be exceeded under normal operation. These limits are enforced to ensure system stability and cannot be adjusted.

• Soft limits can be adjusted by Temporal Cloud based on usage or upon request.
  Some limits automatically increase as your usage grows.
  Temporal Cloud monitors usage and raises these limits as needed, so you don’t need to take action.
  For example, if your number of Namespaces or rate of Actions per second (APS) increases, Temporal Cloud will allocate more resources to keep up.
  You can request changes to any soft limit—whether managed automatically or not—by reaching out to Support.

The following table lists Temporal Cloud's soft limits, indicating whether they are automatically managed based on usage:

Limit	Managed by Temporal Cloud	Adjustable via Support Request
Number of Namespaces	✅	✅
APS (Actions Per Second)	✅	✅
RPS (Requests Per Second)	✅	✅
Number of users		✅
Number of Schedules		✅
Concurrent Task pollers		✅
Batch jobs		✅
Nexus endpoints		✅

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 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

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.

Which calls are subject to the Visibility API rate limit?

• GetWorkerTaskReachability
• ListSchedules
• ListBatchOperations
• DescribeTaskQueueWithReachability
• ListDeployments
• GetDeploymentReachability

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:

• ScheduleActivityTask
• SignalExternalWorkflowExecution
• StartChildWorkflowExecution
• RequestCancelExternalWorkflowExecution

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 Callback limits

What is the maximum number of Callbacks that can be attached to a single Workflow Execution?

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

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.

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.