Skip to main content

Service availability

View Markdown

This page covers the throughput and latency of Temporal Cloud. For the regions you can run in, see Service regions; for the full set of rate, resource, and configuration limits, see System limits.

Throughput​

Each Namespace has a rate limit measured in Actions per second, and two capacity modes control it:

  • On-Demand Capacity raises the Namespace limit automatically as usage grows.
  • Provisioned Capacity sets the limit from the Temporal Resource Units (TRUs) you request, which suits predictable spikes and guaranteed throughput.

See Capacity Modes for how each mode sets your limit.

Latency service level objective (SLO)​

Temporal Cloud has a p99 latency SLO of 200ms per region.

That SLO covers normal Worker requests, meaning commands and polling, and it applies to Nexus in both the caller and handler Namespaces.

Historical latency data​

Measured latency over a week-long period for starting and signaling Workflow Executions, and for starting Standalone Activities (StartActivityExecution), was as follows:

August 2026​

Operationp50p90p99
StartWorkflowExecution20ms32ms78ms
SignalWorkflowExecution19ms42ms91ms
SignalWithStartWorkflowExecution30ms47ms109ms
StartActivityExecution13ms19ms45ms

January 2026​

Operationp50p90p99
StartWorkflowExecution14ms21ms69ms
SignalWorkflowExecution11ms19ms46ms
SignalWithStartWorkflowExecution19ms37ms95ms

March 2024​

Operationp90p99
StartWorkflowExecution24ms54ms
SignalWorkflowExecution14ms40ms
SignalWithStartWorkflowExecution24ms61ms

Latency observed from the Temporal Client also reflects other components in the path, such as the Codec Server, an egress proxy, and the network itself. Concurrent operations on the same Workflow Execution can raise latency as well.

Custom persistence layer​

Temporal Cloud runs a custom persistence layer rather than the persistence stores available to self-hosted deployments. Three components of that layer account for most of the difference in latency:

  • Sharding: Distributes load across multiple databases and resizes them independently, so a traffic spike in one shard doesn't become a bottleneck for the rest.
  • Write-ahead log (WAL): Batches updates in an append-only log before writing them to the database, which reduces write latency and database size.
  • Tiered storage of Event History: Moves the Event History of closed Workflow Executions to cheaper storage, which keeps the primary database smaller and faster for running Executions.