Service Level Agreement (SLA)
Temporal Cloud publishes two numbers for each deployment mode: the service availability it operates to, and the contractual service level agreement (SLA) it guarantees against service errors.
| Deployment mode | Service availability | Contractual SLA |
|---|---|---|
| Standard single-region Namespace | 99.99% | 99.9% |
| Namespace using the High Availability feature | 99.99% | 99.99% |
The SLA that covers normal Worker requests, meaning commands and polling, also covers Nexus requests in both the caller and handler Namespaces.
How the service-error rate is calculated
Temporal Cloud captures every request that arrives in a Namespace during a five-minute interval and records the gRPC service errors among them. For each Namespace, the service-error rate is 1 - (count of errors / count of requests). Rates are averaged per month and reset quarterly.
Errors counted against the SLA are service errors, such as the UNAVAILABLE gRPC status code.
The following errors are not counted against the SLA:
ClientVersionNotSupportedInvalidArgumentNamespaceAlreadyExistsNamespaceInvalidStateNamespaceNotActiveNamespaceNotFoundNotFoundPermissionDeniedQueryFailedRetryReplicationStickyWorkerUnavailableTaskAlreadyStartedThrottling (resources exhausted; triggers retry)WorkflowExecutionAlreadyStartedWorkflowNotReady
How Temporal measures against the SLA
Temporal alerts on a service level objective (SLO) that covers all errors, not only the errors that count against the SLA. A missed SLO pages an on-call engineer, so many issues are resolved before they are noticeable.
Temporal Cloud runs a cell architecture. Each cell holds the software and services needed to host a Namespace, and the components in a cell are distributed across at least three availability zones per region.
For current system status and recent incidents, see Temporal Status.