What is the operating envelope of Temporal Cloud?
The operating envelope of Temporal Cloud includes availability, regions, throughput, and latency. If you need more details, contact us.
What is Temporal Cloud's SLA on Availability?
Temporal Cloud provides 99.99% availability, and its service level agreement (SLA) has a 99.9% guarantee against service errors.
To calculate the service-error rate, we capture all requests that arrive in a region during a five-minute interval and record the number of gRPC service errors that occurred.
For each region, we calculate the service-error rate as 1 - (count of errors / count of requests).
Rates are averaged per month and reset quarterly.
Errors that are recorded against the SLA are service errors, such as the UNAVAILABLE gRPC status code.
Errors that aren't counted against the SLA include the following:
- ClientVersionNotSupported
- InvalidArgument
- NamespaceAlreadyExists
- NamespaceInvalidState
- NamespaceNotActive
- NamespaceNotFound
- NotFound
- PermissionDenied
- QueryFailed
- RetryReplication
- ShardOwnershipLost
- StickyWorkerUnavailable
- TaskAlreadyStarted
- Throttling (resources exhausted; triggers retry)
- WorkflowExecutionAlreadyStarted
- WorkflowNotReady
Our internal alerting system is based on our service level objectives (SLO) for all errors, not just errors that count against the SLA. When we receive an alert that an SLO is not being met, we page our on-call engineers, which often means that issues are resolved before they become noticeable.
Internally, our components are distributed across a minimum of three availability zones per region.
For current system status and information about recent incidents, see Temporal Status.
Where is Temporal Cloud hosted and running?
Temporal Cloud currently runs in the following regions in Amazon Web Services (AWS):
| Area | Code | Region |
|---|---|---|
| Asia Pacific | ap-northeast-1 | Tokyo |
| Asia Pacific | ap-south-1 | Mumbai |
| Asia Pacific | ap-southeast-1 | Singapore |
| Asia Pacific | ap-southeast-2 | Sydney |
| Europe | eu-central-1 | Frankfurt |
| Europe | eu-west-1 | Ireland |
| Europe | eu-west-2 | London |
| North America | ca-central-1 | Central Canada |
| North America | us-east-1 | Northern Virginia |
| North America | us-east-2 | Ohio |
| North America | us-west-2 | Oregon |
| South America | sa-east-1 | São Paulo |
Furthermore, it is compatible with applications deployed in any cloud environment or data center.
To reduce latency, we recommend that you create your Namespace in a region that is geographically close to where your Workers are hosted, but your Workers and Client code don't need to be hosted on AWS.
What kind of throughput can I get with Temporal Cloud?
A Namespace has a default quota of 200 Actions per second with spikes up to 400 Actions per second. However, Temporal Cloud can provide more than 150,000 Actions per second.
If your Action rate exceeds your quota, Temporal Cloud throttles Actions until the rate matches your quota. Actions like Start or Signal Workflow Execution always receive higher priority than other Actions, even when throttled.
To raise your quota, create a support ticket.
What kind of latency can I expect from Temporal Cloud?
Temporal Cloud aims for a latency SLO of 200ms per region for p99. In June 2023, Temporal measured latency over a week-long period for starting and signaling Workflow Executions as follows:
- For
StartWorkflowExecution: p90 latecy was 90ms, and p99 latency was 125ms. - For
SignalWorkflowExecution: p90 latency was 53ms, and p99 latency was 95ms. - For
SignalWithStartWorkflowExecution: p90 latency was 87ms, and p99 latency was 116ms.
As Temporal continues working on improving latencies, these numbers will progressively decrease.
Latency observed from the Temporal Client is influenced by other system components like the Codec Server, egress proxy, and the network itself. Increased latency might result from concurrent operations on the same Workflow Execution.
What are the Temporal Cloud default limits?
This section describes many of the default settings and limits that apply to application operations in Temporal Cloud.
Some of these default limits are configurable by sending a ticket to our support team.
What is the maximum length for identifiers?
Identifiers such as Workflow Id, Workflow Type, and Task Queue names have a maximum length of 1,000 characters in UTF-8 format.
This default limit is configurable by creating a support ticket.
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.
What is the limit for History transaction size?
The DefaultTransactionSizeLimit is configured at 4 MB, representing the maximum allowable transaction size for persisting Event Histories.
What are the default limits at the Namespace level?
At the Namespace level, Temporal Cloud sets the following default limits:
- Actions per second: 200 (with spikes to 400)
- Certificates: 32 KB payload or 16 certificates, whichever is smaller
- Concurrent Task pollers: 2,000 (configurable; maximum of 100,000)
What are the concurrecy 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
These default limits are configurable by creating a support ticket.
Batch jobs are limited to one job running at a time per Namespace.
What is the limit on the number of Signals received per Workflow Execution?
10,000 Signals per Workflow Execution is the default limit and is set on the Namespace level.
What are the default limits for users and Namespaces at the account level?
At the account level, Temporal Cloud sets the following default limits:
- Users: 100
- Namespaces: 10
How much data does the Prometheus endpoint retain?
The Prometheus endpoint retains 30 days of data. This limit is set on the account level.
What is the default Retention Period in your Temporal Cloud Account?
Temporal Cloud sets the default Retention Period to 30 days, and it is configurable in the Temporal Web UI per Namespace. You can set the Retention Period between 1 and 90 days.
What are the default maximum numbers of Custom Search Attributes?
The default maximum number of Custom Search Attributes of each type in Temporal Cloud, you can create per Namespace, are:
bool: 20double: 20datetime: 20int: 20keyword: 20text: 5
For more information on limits on the number and size of custom Search Attributes you can create, see Custom Search Attributes limits.
Are there any limitations on List Filters?
Yes, the ORDER BY operator isn't supported in List Filters in Temporal Cloud.
This means that custom ordering of Workflows with Cloud Visibility features isn't possible. Lists of Workflows are still ordered by a default ordering rule, but be aware that this rule might change.