# Service availability - Temporal Cloud

> For the complete documentation index, see [llms.txt](https://docs.temporal.io/llms.txt).
> Any documentation page is available as raw Markdown by appending `.md` to its URL.

> Temporal Cloud offers high availability and low latency across multiple cloud provider regions with adjustable throughput limits and robust latency targets. Contact us for more details.

The operating envelope of Temporal Cloud includes throughput, latency, and limits.
Service regions are listed on [this page](/cloud/regions).
If you need more details, [contact us](https://pages.temporal.io/contact-us).

## Throughput expectations 

**What kind of throughput can I get with Temporal Cloud?**

Each Namespace in Temporal has a rate limit, which is measured in [Actions](/cloud/pricing#action) per second. 
Temporal offers two different modes for adjusting capacity: On-Demand Capacity or Provisioned Capacity.
With On-Demand Capacity, Namespace capacity is increased automatically along with usage.
With Provisioned Capacity, you can control your capacity limits by requesting Temporal Resource Units (TRUs).

## Latency Service Level Objective (SLO) 

**What kind of latency can I expect from Temporal Cloud?**

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

The same SLO for normal Worker requests (commands and polling) apply to Nexus in both the caller and handler Namespaces.

### Historical latency data

Latency over a week-long period for starting and signaling Workflow Executions was as follows:

#### August 2026

| Operation                          | p50  | p90  |  p99 |
| :--------------------------------- | :--: | :--: | ---: |
| `StartWorkflowExecution`           | 20ms | 32ms | 78ms |
| `SignalWorkflowExecution`          | 19ms | 42ms | 91ms |
| `SignalWithStartWorkflowExecution` | 30ms | 47ms | 109ms |

#### January 2026

| Operation                          |  p50   | p90  |  p99 |
| :--------------------------------- | :----: | :--: | ---: |
| `StartWorkflowExecution`           | 14ms | 21ms | 69ms |
| `SignalWorkflowExecution`          | 11ms | 19ms | 46ms |
| `SignalWithStartWorkflowExecution` | 19ms | 37ms | 95ms |

#### March 2024

| Operation                          | p90  |  p99 |
| :--------------------------------- | :--: | ---: |
| `StartWorkflowExecution`           | 24ms | 54ms |
| `SignalWorkflowExecution`          | 14ms | 40ms |
| `SignalWithStartWorkflowExecution` | 24ms | 61ms |

Latency observed from the Temporal Client is influenced by other system components like the Codec Server, egress proxy, and the network itself.
Also, concurrent operations on the same Workflow Execution may result in higher latency.

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

## Related

- [Higher throughput and lower latency: Temporal Cloud's custom persistence layer](https://temporal.io/blog/higher-throughput-and-lower-latency-temporal-clouds-custom-persistence-layer): How sharding, the write-ahead log, and tiered storage are built.
- [Benchmarking latency: Temporal Cloud vs. self-hosted Temporal](https://temporal.io/blog/benchmarking-latency-temporal-cloud-vs-self-hosted-temporal): Measured comparison of the two deployment options.
- [Replay conference talk: Custom persistence layer](https://www.youtube.com/watch?v=SQv9ot-jB6o&list=PLl9kRkvFJrlREHL7fiEKBWTp5QuFeYS2r&index=5): Walkthrough of the persistence design.