Temporal Cloud

The simple, secure, scalable way to power your Temporal applications.

  • Namespace on demand in 7 regions
  • > 150,000 actions per second
  • 99.9% uptime
  • 1–90 days retention

Just the fine print, please.

Temporal Cloud Planet

Durable Execution

  • Temporal Cloud directs the reliable execution of actions: the basis for your Temporal applications
  • Compatible with all supported languages and versions of the Temporal SDK
  • Keeps a running, durable ledger for recoverability and correctness
  • Works with your application code, however or wherever it runs
pointer graphicTemporal Cloud Planet


  • Container for your application's durable executions.
  • Isolates the security, performance, and cost of durable execution for each application or element of your landscape
  • Self-service provisioned in minutes
  • Extended retention periods for operational & compliance
pointer graphicTemporal Cloud Planet
pointer graphicTemporal Cloud Planet

Temporal Cloud

  • Operates 24×7 in 7 regions on 3 continents
  • 99.9% SLA running across multi-availability zones
  • SOC2 compliant
  • Public uptime reporting
pointer graphicTemporal Cloud Planet
Simplify your development

Simplify your development

No sizing, sharding, tuning, or upgrades. Namespace-as-a-Service, for development or production, on demand.

Lower your costs

Lower your costs

Pay only for what you use, not what you might need. Spend less on infrastructure and staff to run your applications.

Standardize your operations

Standardize your operations

Comprehensive, audited security by default. Predictable uptime and performance.


Simple, transparent, and controllable.

Pricing automatically adjusts based on volume within a namespace.

Up to 300 million $0.025 $0.042Up to 10 GB / hour
300 million to 1.5 billion$0.0188 $0.031010 GB to 40 GB / hour
1.5 billion to 7.5 billion$0.0141 $0.02340 GB to 120 GB / hour
7.5 billion to 30 billion$0.0105 $0.018120 GB to 500 GB / hour
30 billion to 150 billion$0.0079 $0.013500 GB to 2,000 GB / hour
150 billion +$0.0059 $0.0102,000 GB + / hour
Volume Duration
(Actions) (Running)
Volume pricing per 1k actions Running pricing per GB / hour
Duration (retained) $0.00042 per GB / hour
Support Base of $200 per month,
or 10% of monthly invoices over $2k

Pay only for what you use. All charges are metered hourly and billed monthly.

The Fine Print

— 01 Operational Envelope

Operational Envelope


  • Temporal Cloud is offering 99.9% SLA per region.
  • Our SLA is measured by capturing all requests coming in during a 5-minute interval and calculating how many errors occurred during that interval. It is then averaged per month, and reset on a quarterly basis. Our SLA per region is calculated as 1 - (count of errors received / count of requests in the region).
  • Errors recorded against the uptime SLA are service failures: e.g. Data Loss or Service Unavailable.
  • Errors not counted against the SLA:
    • ClientVersionNotSupported
    • ShardOwnershipLost
    • InvalidArgument
    • NamespaceAlreadyExists
    • NamespaceNotActive
    • NamespaceNotFound
    • NamespaceInvalidState
    • NotFound
    • PermissionDenied
    • QueryFailed
    • RetryReplication
    • StickyWorkerUnavailable,
    • TaskAlreadyStarted
    • Throttling (resources exhausted - triggers retry)
    • WorkflowExecutionAlreadyStarted
    • WorkflowNotReady
  • Our internal alerting is based on our own SLO for all errors, not just errors counting against the Temporal Cloud SLA. On-call engineers are paged when we receive alerts because of SLOs not being met, which often means that issues are resolved before they become noticeable.
  • Internally, our components are distributed across a minimum of 3 availability zones per region.
  • Recent incidents can be found at https://status.temporal.io/.

Throughput (Action/s)

  • A namespace has a default quota of 100 action/s.
  • Actions can be throttled when they exceed this quota. Actions like Start Workflow Execution and Signal API always receive higher priority than other actions even when throttled.
  • For bursting capabilities, you can increase your default quota. Please reach out to your Temporal Sales Team.


  • Our Latency SLO is 200ms per region for p99.
  • Latency is greatly influenced by the actual throughput of a single workflow. Concurrent operation on the same workflow could lead to increased latency.

— 02 Security


Customer Application & Data Security

Code Execution Boundaries

Temporal Cloud is a managed service environment; it does not manage a customer’s applications or workers. Applications and services written using Temporal’s SDK run in the customer’s computing environment, such as containers (Docker, Kubernetes) or virtual machines (in any hosting environment). Customers have full control over how they secure their applications and services.

Client-side Encryption

Temporal provides a “Data Converter,” a plugin that can be configured to transparently encrypt and decrypt workflow data on the customer side; the Temporal Server does not need decrypted data to operate. If this feature is configured by our customers, data stored in Temporal Cloud remains secure even if the service itself is compromised. Temporal’s Data Converter also allows customers to securely decrypt data in the Temporal UI without sharing encryption material with Temporal.

Temporal Cloud Platform Security


The base unit of isolation in a Temporal environment is the “namespace.” Each customer can have dozens of namespaces associated with their account. Namespaces (regardless of account) cannot interact with other namespaces. Each namespace is available through a secure gRPC (mTLS) endpoint and an HTTPS (TLS) endpoint. These can be made more secure by routing all communication through AWS PrivateLink.

Temporal Cloud is a multi-tenant service by default. Namespaces in the same environment are logically segregated from each other. Namespaces do not share data processing or data storage across regional boundaries.


Communication into and out of namespaces is over mTLS (for gRPC endpoints) or TLS (for HTTPS endpoints). All communication within our production environments is over mTLS 1.3. Data is stored in two separate locations: an Elasticsearch instance used to power the search function in each namespace’s web UI, and our core data storage. Both are encrypted at rest with AES 256 GCM.


Authentication to gRPC endpoints is provided by mTLS on a per-namespace basis. Authentication to HTTPS endpoints are through Auth0, which supports both local and federated logins.


Authorization is managed at the account and namespace level. Users and systems are assigned one or multiple preconfigured roles. Users hold roles of administrators, developers, and read-only users. Systems or application processes hold their own distinct roles.


In addition to extensive system monitoring for operational and availability requirements, we collect and monitor audit logs from the AWS environment, Auth0, and all calls to the gRPC API (which the Web UI uses to populate data). These audit logs can be made available to customers for ingestion into their own security monitoring system


We contract with a third party to perform a full-scope pentest (with the exception of social engineering) at least yearly. Additionally, we perform targeted third-party and internal testing on an ad hoc basis (such as when a significant feature is being released).

Temporal Cloud Access

Access to production systems is restricted to the small team of employees tasked with maintaining our production infrastructure. All access to production systems is logged; shared accounts are not allowed. Access to all production systems is through SSO, with MFA enabled.

All Temporal engineering systems are secured via GitHub credentials, which requires both Temporal GitHub Organization membership and MFA. Access grants are reviewed on a quarterly basis.


Temporal Technologies is SOC 2 Type 2 certified and compliant with GDPR.

— 03 FAQs

Temporal Cloud FAQs

Q: Where does Temporal Cloud run?

A: Temporal Cloud is run in 7 different regions in Amazon Web Services (AWS).

Q: I don’t use Amazon Web Services. When can I use Temporal Cloud?

A: Today! The Temporal Cloud service runs out of AWS regions but it can work with applications running in any cloud or datacenter. It’s more important to align Temporal Cloud namespaces to the regions your application runs in than the particular infrastructure.

Q: What’s the minimum fee to run Temporal Cloud?

A: The Temporal Cloud service is consumption based. You pay only for what you need with no minimum. Business Support has a minimum monthly fee of $200 per month.

Q: How do I pay for Temporal Cloud?

A: We send you a monthly bill based on your consumption. You can pay this bill with a credit card, check, or Temporal Credits.

Q: Can I purchase Temporal Cloud through my Amazon, Azure, or Google Cloud marketplace?

A: Not currently, but we’ll consider adding this option if we see sufficient demand for it.

Q: How do I know what I am spending in Temporal Cloud?

A: We provide up-to-the-hour usage reporting as part of Temporal Cloud. In the future, we plan to add the ability to check credit balances and trigger alerts on spend overruns.

Q: You say Temporal Cloud scales up to 150 actions per second “on demand” but 150,000 actions per second “on request.” What’s the difference and what does that mean?

A: Any namespace you provision in Temporal Cloud is capable of running up to 150 actions per second without any need to configure or explicitly request. If you file a support ticket with Temporal you can scale as high as 150,000 APS.

As we continue to expand the availability of Temporal Cloud, we will continue to increase the ceiling you can scale to without filing a support ticket.

As Reliable As Gravity

tardigradetardigradeasteroidasteroidasteroid top-[153.32px] left-[1047px]asteroidasteroidasteroidasteroidasteroidasteroidasteroidasteroidasteroidasteroidasteroidasteroidasteroidasteroidplanet