> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Step Functions
> AWS Step Functions. Runs workflows as JSON-defined state machines, with retries, error handling, parallel and map states.
Preview
**On this page**
* [Coverage by target cloud](#coverage-by-target-cloud)
* [How the targets compare](#how-the-targets-compare)
* [Max adaptation](#max-adaptation)
* [On Google Cloud](#on-google-cloud)
* [Via Cloud Workflows](#via-cloud-workflows)
* [On Google Cloud, Azure, OCI, and Private Kubernetes](#on-google-cloud-azure-oci-and-private-kubernetes)
* [Via Temporal (Self-Hosted)](#via-temporal-self-hosted)
* [Via Temporal Cloud (Managed)](#via-temporal-cloud-managed)
* [On Azure](#on-azure)
* [Via Azure Durable Functions](#via-azure-durable-functions)
* [State-machine administration](#state-machine-administration)
* [On Google Cloud](#on-google-cloud-2)
* [On Google Cloud, Azure, OCI, and Private Kubernetes](#on-google-cloud-azure-oci-and-private-kubernetes-2)
* [On Azure](#on-azure-2)
* [Service level agreements](#service-level-agreements)
* [Step Functions to Azure Durable Functions](#step-functions-to-azure-durable-functions)
* [Step Functions to Cloud Workflows](#step-functions-to-cloud-workflows)
* [Step Functions to Temporal Cloud (Managed)](#step-functions-to-temporal-cloud-managed)
* [Step Functions to Temporal (Self-Hosted)](#step-functions-to-temporal-self-hosted)
* [Step Functions State Machine to Azure Durable Functions](#step-functions-state-machine-to-azure-durable-functions)
* [Step Functions State Machine to Cloud Workflows](#step-functions-state-machine-to-cloud-workflows)
* [Step Functions State Machine to Temporal Cloud (Managed)](#step-functions-state-machine-to-temporal-cloud-managed)
* [Step Functions State Machine to Temporal (Self-Hosted)](#step-functions-state-machine-to-temporal-self-hosted)
* [Debug this service](#debug-this-service)
## Coverage by target cloud
| Target | Available |
| ------------------ | --------- |
| Google Cloud | ✓ |
| Azure | ✓ |
| OCI | ✓ |
| Private Kubernetes | ✓ |
## How the targets compare
Each row compares a capability of Step Functions with its adaptation on each target.
A dash means this row is not stated for that target.
### Max adaptation
| Capability | Step Functions | Google Cloud · Cloud Workflows | Google Cloud, Azure, OCI, and Private Kubernetes · Temporal (Self-Hosted) | Google Cloud, Azure, OCI, and Private Kubernetes · Temporal Cloud (Managed) | Azure · Azure Durable Functions |
| ----------------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Execution engine · what runs the state machine | the Step Functions service interprets the Amazon States Language definition | Cloud Workflows runs workflow modules the adapter prepares from the definition per revision, with ASL data and expression semantics from an adapter helper the workflow calls; an Express execution runs inline in the adapter | - | - | a Tensor9-maintained orchestrator function on Azure Functions interprets the same definition, one Durable Functions orchestration per Standard execution; an Express execution runs inline in the adapter |
| Execution state · where progress is checkpointed | held by the service | held by Cloud Workflows per execution; the adapter keeps the execution's identity, input and outcome | - | - | checkpointed in a task hub in an Azure Storage account; an execution survives a restart of the function app or of the adapter |
| Long-running executions · Wait states and timeouts | up to one year; a Wait state holds no compute | up to one year, the Workflows ceiling; a Wait is the engine's own sleep | - | - | up to one year; a Wait is a durable timer held in the task hub |
| Express workflows · 5-minute, high-volume runs | at-least-once asynchronous runs and at-most-once synchronous runs, no API history | an inline run in the adapter with no durable record, within the 5-minute ceiling and with no API history; a fresh start is never deduplicated | - | - | an inline run in the adapter with no durable record, within the 5-minute ceiling and with no API history; a fresh start is never deduplicated |
| Activities and task tokens · work handed to outside workers | a service-hosted queue polled by GetActivityTask | a queue the adapter serves; the token is minted by the adapter and completion resumes the workflow through its callback | - | - | a queue the adapter serves; the token is minted and checked by the adapter, and workers reach the adapter's endpoint |
| Definition size · the largest state machine | 1 MB of Amazon States Language | 1 MB accepted; split across prepared modules because one Workflows source is capped at 128 KB | - | - | - |
| Service integrations · what a Task state can call | AWS services through optimized and SDK integrations | the services adapted on the same appliance, through their own mappings; a Resource the appliance does not serve is refused at CreateStateMachine | - | - | the services adapted on the same appliance, through their own mappings; a Resource the appliance does not serve is refused at CreateStateMachine |
| Logs and traces · where execution logs go | CloudWatch Logs and X-Ray | Cloud Logging captures execution and step logs; X-Ray tracing is not reproduced | - | - | the appliance's logging; X-Ray tracing is not reproduced |
| API coverage | full | partial | partial | partial | partial |
| Execution engine | Step Functions interprets ASL | - | a generic Tensor9-maintained Temporal workflow interprets Standard executions; Express runs separately in the adapter | a generic Tensor9-maintained Temporal workflow interprets Standard executions; Express runs separately in the adapter | - |
| Execution state | AWS holds state and history | - | self-hosted Temporal holds native history; the adapter retains AWS identities and public records | Temporal Cloud holds native history in the namespace region; the adapter retains AWS identities and public records | - |
| Activities and callbacks | AWS hosts Activity queues and accepts task tokens | - | the adapter serves Activity queues and durable token completion; Temporal activities perform internal service calls | the adapter serves Activity queues and durable token completion; Temporal activities perform internal service calls | - |
| Service integrations | optimized and SDK integrations with AWS services | - | only supported service mappings and invocation patterns in the deployment | only supported service mappings and invocation patterns in the deployment | - |
| Execution debugging | AWS console, CloudWatch Logs and X-Ray | - | Temporal Web UI and deployment logs; the AWS graph and X-Ray tracing are not reproduced | Temporal Web UI and deployment logs; the AWS graph and X-Ray tracing are not reproduced | - |
| Capacity | service quotas govern concurrency | - | cluster, database and worker capacity govern throughput; the deployment operator maintains them | namespace and worker capacity govern throughput; customer billing covers Temporal Cloud and worker compute | - |
| Versions and aliases · immutable versions, weighted routing | native | - | - | - | adapter records; an execution pins the version it was routed to |
## On Google Cloud
### Via Cloud Workflows
| Capability | Area | Support | Required tier | Operations | Notes |
| ----------------------------- | ---------------------- | ------------ | ------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data flow and expressions | Amazon States Language | Supported | - | - | InputPath, Parameters, ResultSelector, ResultPath, OutputPath, intrinsic functions, JSONata, variables and Assign are evaluated for the workflow by an adapter helper, since the Workflows language has no equivalent |
| Distributed Map | Amazon States Language | Supported | - | - | a Map Run fans out into child Workflows executions scheduled by the parent within MaxConcurrency; item slots and ordered output survive a restart, an item retry never becomes a whole-Map retry, and UpdateMapRun reaches children already running or fails with a named error. A large Map Run is paced by shared admission and backpressure without any change to its semantics |
| Error handling | Amazon States Language | Supported | - | - | Retry and Catch with backoff, jitter and error matching; one ASL attempt is one submission, never multiplied by the platform's own retry |
| Parallel and inline Map | Amazon States Language | Supported | - | - | Cloud Workflows nests parallel steps two deep and runs 20 branches at once within one execution; a Parallel or Map beyond that runs its branches as child executions, so the definition's shape is preserved |
| Wait states and timeouts | Amazon States Language | Supported | - | - | a Wait is served by the engine itself, which sleeps within the execution for up to a year; state and execution timeouts fire as States.Timeout |
| Encryption configuration | Configuration | Supported | - | - | a customer-managed key names a key served by the KMS mapping on the same appliance (Cloud KMS on Google Cloud); the definition, the prepared modules' data and execution payloads are encrypted under it and become unreadable when it is revoked |
| Logging configuration | Configuration | Partial | - | - | includeExecutionData decides whether execution payloads are written at all, and the configured destination decides whose log they reach; the entries land in Cloud Logging, since CloudWatch Logs is a service the appliance does not adapt |
| Tracing configuration | Configuration | Out of scope | - | - | X-Ray is not adapted, so a configuration that enables tracing is rejected at CreateStateMachine and UpdateStateMachine rather than stored and ignored |
| EXPRESS workflows | Execution model | Supported | - | - | an Express execution is an inline run in the adapter with no durable record, within the 5-minute ceiling; as on AWS it has no history through the API, cannot use Activities, Distributed Map, .sync or .waitForTaskToken, and DescribeStateMachineForExecution, GetExecutionHistory, ListExecutions, RedriveExecution and StopExecution refuse it. A fresh Express start is never deduplicated, and an interrupted delivery is retried under the same accepted start |
| STANDARD workflows | Execution model | Supported | - | - | exactly-once execution with a durable record, up to one year, which is also the ceiling of a Cloud Workflows execution |
| Service integrations | Integrations | Partial | - | - | a Task Resource naming an AWS service is served by that service's mapping on the same appliance, including .sync and .waitForTaskToken, nested executions and Task.Credentials role overrides; a Resource naming a service the appliance does not serve is refused at CreateStateMachine |
| Payload and definition limits | Limits | Supported | - | - | the 256 KiB payload ceiling and the 1 MB definition ceiling are enforced at the API; a definition larger than Workflows' 128 KB source limit is split across prepared modules, so the AWS ceiling is the one you plan against |
| Operation | Area | Support | Depth | Notes |
| -------------------------------- | -------------------- | -------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| CreateActivity | Activities | Adapter-served | Most usage | an Activity is a record and a task queue the adapter serves; Cloud Workflows has callback endpoints but nothing an outside worker long-polls by name |
| DeleteActivity | Activities | Adapter-served | Full surface | deletes the Activity even while workers hold tasks from it, as on AWS; a worker's next SendTaskSuccess for such a task answers TaskDoesNotExist |
| DescribeActivity | Activities | Adapter-served | Full surface | returns the Activity's ARN, name and creation date |
| GetActivityTask | Activities | Adapter-served | Most usage | holds the poll open for up to 60 seconds and hands one task to one worker with an adapter-minted token; an empty poll returns a null token |
| ListActivities | Activities | Adapter-served | Full surface | lists the Activities |
| SendTaskFailure | Activities | Adapter-served | Most usage | fails the task with the error and cause supplied |
| SendTaskHeartbeat | Activities | Adapter-served | Full surface | renews the heartbeat window; a lapsed heartbeat fails the task with States.Timeout |
| SendTaskSuccess | Activities | Adapter-served | Most usage | completes the task the token identifies, once; the waiting Workflows execution resumes through its callback |
| TestState | Diagnostics | Supported | Full surface | evaluates a single state without starting an execution; a Task state that reaches a real service does so under the caller's own authorization |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | validates a definition without creating anything and returns diagnostics with severity; a Task whose Resource names a service the appliance does not serve is reported here |
| DescribeMapRun | Distributed Map | Supported | Most usage | returns the Map Run's status, item counts, tolerated-failure settings and concurrency |
| ListMapRuns | Distributed Map | Supported | Full surface | lists the Map Runs of an execution |
| UpdateMapRun | Distributed Map | Supported | Full surface | changes MaxConcurrency or the tolerated-failure thresholds of a running Map Run; children in flight continue |
| DescribeExecution | Executions | Supported | Common | returns status, input, output, error, cause and redrive details |
| GetExecutionHistory | Executions | Supported | Most usage | returns the execution's transitions as Step Functions events in causal order, derived from the adapter's record and the Workflows execution; EXPRESS executions have no history through the API, as on AWS |
| ListExecutions | Executions | Supported | Common | lists executions by state machine or Map Run with status and redrive filters |
| RedriveExecution | Executions | Supported | Most usage | resumes a failed, aborted or timed-out STANDARD execution from its unsuccessful states within 14 days, under the same execution ARN and revision; successful states are not rerun and only failed Map Run children restart |
| StartExecution | Executions | Supported | Common | admits the execution, pins its revision and runs it: a STANDARD execution as a Cloud Workflows execution of that revision's prepared workflow under the workflow's own service account, an EXPRESS execution as an inline run in the adapter with no durable record. STANDARD starts are idempotent on name and input while the execution runs, ExecutionAlreadyExists is returned for a closed execution or a different input, and a name is reusable 90 days after closing; EXPRESS starts are never deduplicated |
| StartSyncExecution | Executions | Supported | Most usage | the synchronous result API of an EXPRESS state machine: the request is held open until the inline run completes or the 5-minute ceiling passes, a failed run is reported in the response body, and a caller that disconnects does not cancel accepted work |
| StopExecution | Executions | Supported | Common | cancels the Workflows execution and records the ABORTED outcome with the error and cause supplied |
| CreateStateMachine | State machines | Supported | Common | validates the definition, records the state machine, and prepares for that revision an immutable set of workflow modules and a manifest in Cloud Workflows; the definition itself is kept as written |
| DeleteStateMachine | State machines | Supported | Common | succeeds at once and reads DELETING until running executions complete; the prepared modules of its revisions are retired with it |
| DescribeStateMachine | State machines | Supported | Common | returns the definition, role, type, revision and configuration from the adapter's record |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | returns the definition and revision the execution is pinned to |
| ListStateMachines | State machines | Supported | Common | lists state machines with opaque pagination tokens |
| UpdateStateMachine | State machines | Supported | Common | returns a new revision with its own prepared modules; executions in flight keep the revision and modules they started on |
| ListTagsForResource | Tags | Supported | Full surface | lists the tags |
| TagResource | Tags | Supported | Full surface | attaches tags to a state machine or Activity |
| UntagResource | Tags | Supported | Full surface | removes tags |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | an alias routes to one or two versions by weight; an execution pins the version it was routed to |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | deletes the alias; executions it routed keep running |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | deletes a version; refused while an alias still routes to it |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | returns the alias and its routing |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | lists the aliases |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | lists the published versions |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | publishes the current revision as an immutable numbered version; the version shares the revision's prepared modules |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | changes the routing for executions started afterwards |
#### How it works
Your application keeps calling the Step Functions API. On Google Cloud those calls reach a Tensor9 service adapter instead of AWS. The adapter holds each state machine as a record (the Amazon States Language definition as you wrote it, the role, the type, the versions, the aliases and the tags) and answers every `states:` operation from that record and from the executions it has admitted.
Cloud Workflows executes its own language, so for each revision of a state machine the adapter prepares an immutable set of bounded workflow modules and a manifest in Cloud Workflows. Four quotas make that split necessary: a single workflow source is capped at 128 KB against the 1 MB an ASL definition may be, parallel steps nest two deep, 20 branches run at once within one execution, and variables, arguments and events share 512 KB. A Parallel or Map that exceeds the depth or width runs its branches as child executions; a large definition spans several modules. Data flow and expression semantics (paths, intrinsics, JSONata, Choice rules) are evaluated by an adapter helper the workflow calls, so ASL behaves as it does on AWS rather than as an approximation in the Workflows language.
StartExecution admits the execution and pins its revision. A Standard execution runs as a Workflows execution of that revision's prepared workflow; an Express execution runs inline in the adapter and leaves no durable record, as on AWS. The workflow runs under a service account the adapter creates for that revision, so its calls to other services present an identity of their own and are authorized per workflow rather than for the whole project. A Task state's Resource names an AWS service and is served by that service's mapping on the same appliance; a `.waitForTaskToken` integration parks the execution on a Workflows callback until SendTaskSuccess or SendTaskFailure arrives. Each Task effect is authorized against the state machine's execution role, or the Task.Credentials role where one is set, before it is made. GetExecutionHistory returns Step Functions events built from the adapter's record and the Workflows execution in causal order.
#### Infrastructure-only translation
A deployment that translates infrastructure only, with no adapter, treats the state machine as a Terraform resource. The Tensor9 compiler emits a Cloud Workflows workflow with the state machine's name in the appliance's region and stops there: the Amazon States Language definition has no mechanical translation to the Workflows language (Task, Wait, Choice, Map and Parallel states against Workflows steps, switch, try/retry/except, for and parallel), so the workflow's source is left unset and reported as an omission, and the logic must be re-authored by hand in Workflows YAML. The execution role, an EXPRESS type, the logging configuration and tags are reported as lossy for the same reason: the role is a separate IAM object with no service-account email to bind, Workflows has one durable execution model, logging is a Cloud Logging setting, and label keys must be lowercase without dots.
That path exists so a deployment with a state machine still produces a valid Google Cloud stack; it does not answer the Step Functions API, and an application that calls `states:` needs the adapter above.
#### Limitations
* **Activities are served by the adapter.** Cloud Workflows has callback endpoints but no resource a worker outside the platform long-polls by name, so an Activity is a queue the adapter serves: GetActivityTask holds the poll open for up to 60 seconds, the token is minted by the adapter, and a completion resumes the workflow through its callback. Workers need no code change; they must reach the adapter's endpoint. - **Large Map Runs are paced by the appliance.** A Map Run becomes child Workflows executions within MaxConcurrency, and a Parallel or inline Map wider than 20 branches also runs as child executions. A large Map Run is admitted with backpressure rather than all at once; its semantics do not change, and an UpdateMapRun that cannot reach children already running fails with a named error instead of reporting a change that did not happen. - **A ceiling reached mid-execution is named.** Cloud Workflows has budgets of its own, such as its step budget per execution. When one is reached inside a window AWS would still honour, the execution fails with an error naming the ceiling rather than as an ordinary timeout, and a task token outstanding for as long as AWS allows is either honoured or fails the same way. - **Definitions span modules.** A definition larger than 128 KB, or nested deeper than Workflows allows, is split across prepared modules. The split is the adapter's and is invisible to the API, but the prepared workflows are visible in the Google Cloud console, named per revision. - **Logs and traces do not reach CloudWatch or X-Ray.** `includeExecutionData` decides whether execution payloads are written at all and the configured destination decides whose log they reach; the entries land in Cloud Logging, since CloudWatch Logs is a service the appliance does not adapt. A `tracingConfiguration` that enables X-Ray tracing is rejected at CreateStateMachine and UpdateStateMachine rather than stored and ignored. - **Service integrations are bounded by the appliance.** A Resource naming a service the appliance does not serve is reported by ValidateStateMachineDefinition and refused at CreateStateMachine with an error naming the state. - **Without the adapter, the definition does not come across.** The infrastructure-only translation emits the Workflows shell and leaves its source unset; the state machine's logic must be re-authored by hand. - **The engine choice is fixed per execution.** Which engine runs a state machine is chosen per deployment and recorded with each execution. Changing it affects executions started afterwards; executions already running, their history and their outstanding task tokens stay on the engine they started on until they complete and their retention expires. Nothing migrates a live execution.
#### Other considerations
* **Migration.** State machines are created by your own deployment through CreateStateMachine, versions and aliases included; the adapter prepares each revision's modules at that point. Executions do not migrate, and AWS execution history is not copied. - **Who operates what.** Google operates Cloud Workflows and stores each execution's state and history for 90 days after it completes. Tensor9 operates the adapter, the prepared modules and the helper service; an adapter upgrade leaves a revision's prepared modules in place, so a running execution keeps the code it started with. - **Cost shape.** AWS bills a Standard execution per state transition. Cloud Workflows bills per step executed and per external call, and the adapter helper's evaluations count as external calls. - **What you see in the Google Cloud console.** Workflows named per revision and their executions, under the per-revision service accounts the adapter creates. State machines, execution ARNs and versions exist in the adapter's record and are what the Step Functions API returns.
## On Google Cloud, Azure, OCI, and Private Kubernetes
### Via Temporal (Self-Hosted)
| Capability | Area | Support | Required tier | Operations | Notes |
| ----------------------------- | ---------------------- | ------------ | ------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| ASL state types and data flow | Amazon States Language | Supported | - | - | Pass, Succeed, Fail, Choice, Wait, Task, Parallel and Map use the generic interpreter, including paths, intrinsic functions, JSONata, variables and Assign. |
| Map and Parallel | Amazon States Language | Supported | - | - | Child workflows preserve branch and item ordering, dynamic concurrency, item-level retries and failure thresholds. Capacity admission may delay runnable items. |
| Retry, Catch and timeouts | Amazon States Language | Supported | - | - | The interpreter controls ASL retries, error matching, backoff and jitter; transport retries do not silently add business attempts. Temporal timers drive waits and timeout handling. |
| Encryption configuration | Configuration | Supported | - | - | Customer-managed encryption uses the deployment's KMS mapping for adapter records and a worker payload codec for Temporal payloads; decoded history requires key authorization. |
| Logging configuration | Configuration | Partial | - | - | The configured destination and includeExecutionData setting control deployment logs. Logs do not reach AWS CloudWatch Logs. |
| Tracing configuration | Configuration | Out of scope | - | - | Enabling AWS X-Ray tracing is rejected; X-Ray is not supplied by this mapping. |
| EXPRESS workflows | Execution model | Supported | - | - | The adapter executes Express separately within five minutes, without Standard API history. Activities, Distributed Map, .sync, callbacks and Standard-only execution APIs are unavailable for Express. |
| STANDARD workflows | Execution model | Supported | - | - | Temporal persists Standard execution history and timers. The interpreter preserves the execution identity across worker restart and continue-as-new; external side effects retain their integration's idempotency rules. |
| Service integrations | Integrations | Partial | - | - | Task resources, .sync, .waitForTaskToken and Task.Credentials are supported only where the deployment has the corresponding service mapping and authorization. Unsupported combinations are rejected at admission. |
| AWS visual console | Operator interface | Out of scope | - | - | Temporal Web UI shows workflow history, timers and pending work. It does not reproduce the AWS console's ASL graph and highlighted execution path. |
| Operation | Area | Support | Depth | Notes |
| -------------------------------- | ------------------------ | -------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| CreateActivity | Activities | Adapter-served | Most usage | Creates an AWS Activity record and a durable task queue served by the adapter; it is separate from Temporal's internal activities. |
| DeleteActivity | Activities | Adapter-served | Full surface | Deletes the Activity and refuses subsequent completion for removed tasks. |
| DescribeActivity | Activities | Adapter-served | Full surface | Returns the Activity ARN, name and creation time. |
| GetActivityTask | Activities | Adapter-served | Most usage | Long-polls the adapter queue and gives one worker a task and attempt-specific token; workers connect to the adapter endpoint. |
| ListActivities | Activities | Adapter-served | Full surface | Lists Activity records with pagination. |
| SendTaskFailure | Activities and callbacks | Adapter-served | Most usage | Records the active attempt's error and cause and resumes ASL error handling. |
| SendTaskHeartbeat | Activities and callbacks | Adapter-served | Full surface | Renews the active task's heartbeat window without extending its absolute timeout. |
| SendTaskSuccess | Activities and callbacks | Adapter-served | Most usage | Durably records completion of the active task attempt and wakes the Temporal workflow; stale tokens are refused and a transport acknowledgment is insufficient. |
| TestState | Diagnostics | Supported | Full surface | Evaluates a single state through the same ASL evaluator; an external Task call requires the caller's authorization and a supported integration. |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | Validates ASL without creating a resource and reports diagnostics, including unsupported Task resources and invocation patterns. |
| DescribeMapRun | Distributed Map | Supported | Most usage | Returns Map Run status, item counts, concurrency and tolerated-failure settings. |
| ListMapRuns | Distributed Map | Supported | Full surface | Lists an execution's Map Runs. |
| UpdateMapRun | Distributed Map | Supported | Full surface | Updates concurrency and failure thresholds in the running interpreter; an update that cannot reach it fails explicitly. Existing child work is retained. |
| DescribeExecution | Executions | Supported | Common | Returns Standard execution status, input, output, failure and redrive details through the adapter's execution record. |
| GetExecutionHistory | Executions | Supported | Most usage | Returns Step Functions events in causal order, including event links and timestamps; Temporal history is translated into the public event model. Express has no API history. |
| ListExecutions | Executions | Supported | Common | Lists Standard executions by state machine or Map Run, with status filters and pagination. |
| RedriveExecution | Executions | Supported | Most usage | Resumes eligible unsuccessful Standard work under the same execution identity and revision within the redrive window; successful states are retained and rerun states reset their retry counters. |
| StartExecution | Executions | Supported | Common | Admits a Standard execution durably and runs the selected ASL revision as a Temporal workflow. Standard name/input deduplication is kept; Express uses a separate short-lived execution path and fresh starts are not deduplicated. |
| StartSyncExecution | Executions | Supported | Most usage | Returns the result of an Express execution within its five-minute limit, including execution failures in the response body; caller disconnection does not cancel accepted work. |
| StopExecution | Executions | Supported | Common | Stops the Standard workflow and records ABORTED with the supplied error and cause; cancellation of an already accepted external effect depends on its integration. |
| CreateStateMachine | State machines | Supported | Common | Validates ASL and stores the definition, role, mode, encryption, logging and tags; unsupported integrations are rejected. |
| DeleteStateMachine | State machines | Supported | Common | Reports DELETING, terminates executions at their next state transition and retires the definition, versions and aliases once executions have closed. Express deletion is eventually consistent. |
| DescribeStateMachine | State machines | Supported | Common | Returns the adapter's definition, role, mode, revision and configuration. |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | Returns the immutable definition and revision selected for a Standard execution. |
| ListStateMachines | State machines | Supported | Common | Lists state machines using opaque pagination tokens. |
| UpdateStateMachine | State machines | Supported | Common | Creates a new revision for subsequent executions; active executions retain their selected definition and runtime version. |
| ListTagsForResource | Tags | Supported | Full surface | Returns the resource's tags. |
| TagResource | Tags | Supported | Full surface | Attaches tags to state-machine or Activity records. |
| UntagResource | Tags | Supported | Full surface | Removes tags from the adapter's resource record. |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | Stores weighted routing to one or two versions; each new execution retains the selected version. |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | Deletes the alias without interrupting executions previously started through it. |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | Deletes an unreferenced version; a version used by an alias cannot be deleted. |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | Returns the alias and routing configuration. |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | Lists aliases with pagination. |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | Lists published versions with pagination. |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | Publishes an immutable numbered revision. |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | Updates routing for subsequent starts; existing executions keep their selected version. |
#### How Step Functions runs on self-hosted Temporal
Your application calls the Step Functions API in the target environment. A Tensor9 service adapter stores state-machine definitions, revisions, versions and aliases. For a Standard execution, a Tensor9-maintained worker reads the selected Amazon States Language definition and interprets it as a Temporal workflow. The same worker runs many definitions; your team does not maintain generated application code.
The Temporal service and its persistence database run in the selected deployment environment. Workers use its task queues, durable timers and execution history to resume after a worker restart. The adapter retains the AWS execution ARN and translates execution status and history back into Step Functions responses. An Express execution uses the adapter's separate, short-lived execution path.
#### Tasks, callbacks and an approval example
A Task Resource identifies an AWS integration, not a Temporal workflow type. The adapter resolves the requested operation through the service mappings available in the deployment and checks the execution role before dispatch. Temporal activities perform external calls; the interpreter controls ASL Retry and Catch so a native retry does not silently create another business attempt. AWS Activities remain a separate queue served through GetActivityTask.
Consider an order awaiting approval through .waitForTaskToken. The adapter associates the token with the active task attempt while the Temporal workflow waits. An authorized SendTaskSuccess or SendTaskFailure call records that attempt's result and wakes the workflow. A transport acknowledgment alone does not complete the task. A .sync task instead observes the submitted job until its terminal result.
Parallel branches and Map items use child workflows. The interpreter retains item order, concurrency limits and the distinction between an item retry and a retry of the containing Map. Continue-as-new and worker upgrades preserve the public execution identity and the definition revision.
#### Debugging and worker upgrades
Temporal Web UI is the operator interface for Standard workflow execution. Its history, pending activities and timers help distinguish a stuck external call from an execution waiting for a callback. It does not reproduce the AWS console's ASL graph or highlighted state path. GetExecutionHistory supplies the Step Functions view of a Standard execution; access to decoded payloads requires separate authorization.
Tensor9 maintains the interpreter and compatible worker versions. Running executions keep their program and evaluator versions during an upgrade. Your deployment operator maintains Temporal service availability, database backups and restoration procedures. Retaining a Helm release without protecting the persistence database is insufficient for recovery.
#### Limitations
Where Step Functions and self-hosted Temporal differ
* **Service integrations depend on the deployment.** A Task can call only an operation and invocation pattern supplied by its service mapping. A Glue or SageMaker ARN does not become executable merely because Temporal can schedule an activity.
* **External effects retain their own retry rules.** Workflow replay does not make a remote, non-idempotent operation safe to submit twice. The integration's recovery and cancellation behavior applies to work already accepted by that service.
* **Capacity comes from the installed cluster.** Worker capacity, persistence throughput and Temporal history limits constrain concurrency. ASL MaxConcurrency is an upper bound, not a throughput reservation.
* **AWS console and telemetry endpoints change.** Use Temporal Web UI and deployment logs. X-Ray tracing is rejected when enabled, and configured logs do not go to AWS CloudWatch Logs.
* **Express has a different execution model.** It has no Standard execution-history API and cannot use Activities, Distributed Map, .sync or .waitForTaskToken.
#### Other considerations
* **Cutover.** Deploy definitions, versions and aliases through the Step Functions API. Existing AWS executions and callbacks finish against AWS; their running state and history are not imported.
* **Operations.** The deployment operator owns the Temporal cluster, persistence, backups, network access and service upgrades. Tensor9 maintains the adapter and interpreter workers. Infrastructure and operating costs include the workers and database as well as the Temporal services.
* **Data and credentials.** Protect both the adapter's records and Temporal's history. Configure authentication and encryption for the cluster and restrict Web UI access; namespace naming alone is not authorization.
* **Changing engines.** A backend change applies to new executions. Retain the old workers, credentials and callback routes until their executions and retention obligations finish.
Temporal documents the [self-hosted service](https://github.com/temporalio/documentation/blob/main/docs/production-deployment/self-hosted-guide/index.mdx) and [Web UI](https://docs.temporal.io/web-ui).
### Via Temporal Cloud (Managed)
| Capability | Area | Support | Required tier | Operations | Notes |
| ----------------------------- | ---------------------- | ------------ | ------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| ASL state types and data flow | Amazon States Language | Supported | - | - | Pass, Succeed, Fail, Choice, Wait, Task, Parallel and Map use the generic interpreter, including paths, intrinsic functions, JSONata, variables and Assign. |
| Map and Parallel | Amazon States Language | Supported | - | - | Child workflows preserve branch and item ordering, dynamic concurrency, item-level retries and failure thresholds. Capacity admission may delay runnable items. |
| Retry, Catch and timeouts | Amazon States Language | Supported | - | - | The interpreter controls ASL retries, error matching, backoff and jitter; transport retries do not silently add business attempts. Temporal timers drive waits and timeout handling. |
| Encryption configuration | Configuration | Supported | - | - | Customer-managed encryption uses the deployment's KMS mapping for adapter records and a worker payload codec for Temporal payloads; decoded history requires key authorization. |
| Logging configuration | Configuration | Partial | - | - | The configured destination and includeExecutionData setting control deployment logs. Logs do not reach AWS CloudWatch Logs. |
| Tracing configuration | Configuration | Out of scope | - | - | Enabling AWS X-Ray tracing is rejected; X-Ray is not supplied by this mapping. |
| EXPRESS workflows | Execution model | Supported | - | - | The adapter executes Express separately within five minutes, without Standard API history. Activities, Distributed Map, .sync, callbacks and Standard-only execution APIs are unavailable for Express. |
| STANDARD workflows | Execution model | Supported | - | - | Temporal persists Standard execution history and timers. The interpreter preserves the execution identity across worker restart and continue-as-new; external side effects retain their integration's idempotency rules. |
| Service integrations | Integrations | Partial | - | - | Task resources, .sync, .waitForTaskToken and Task.Credentials are supported only where the deployment has the corresponding service mapping and authorization. Unsupported combinations are rejected at admission. |
| AWS visual console | Operator interface | Out of scope | - | - | Temporal Web UI shows workflow history, timers and pending work. It does not reproduce the AWS console's ASL graph and highlighted execution path. |
| Operation | Area | Support | Depth | Notes |
| -------------------------------- | ------------------------ | -------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| CreateActivity | Activities | Adapter-served | Most usage | Creates an AWS Activity record and a durable task queue served by the adapter; it is separate from Temporal's internal activities. |
| DeleteActivity | Activities | Adapter-served | Full surface | Deletes the Activity and refuses subsequent completion for removed tasks. |
| DescribeActivity | Activities | Adapter-served | Full surface | Returns the Activity ARN, name and creation time. |
| GetActivityTask | Activities | Adapter-served | Most usage | Long-polls the adapter queue and gives one worker a task and attempt-specific token; workers connect to the adapter endpoint. |
| ListActivities | Activities | Adapter-served | Full surface | Lists Activity records with pagination. |
| SendTaskFailure | Activities and callbacks | Adapter-served | Most usage | Records the active attempt's error and cause and resumes ASL error handling. |
| SendTaskHeartbeat | Activities and callbacks | Adapter-served | Full surface | Renews the active task's heartbeat window without extending its absolute timeout. |
| SendTaskSuccess | Activities and callbacks | Adapter-served | Most usage | Durably records completion of the active task attempt and wakes the Temporal workflow; stale tokens are refused and a transport acknowledgment is insufficient. |
| TestState | Diagnostics | Supported | Full surface | Evaluates a single state through the same ASL evaluator; an external Task call requires the caller's authorization and a supported integration. |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | Validates ASL without creating a resource and reports diagnostics, including unsupported Task resources and invocation patterns. |
| DescribeMapRun | Distributed Map | Supported | Most usage | Returns Map Run status, item counts, concurrency and tolerated-failure settings. |
| ListMapRuns | Distributed Map | Supported | Full surface | Lists an execution's Map Runs. |
| UpdateMapRun | Distributed Map | Supported | Full surface | Updates concurrency and failure thresholds in the running interpreter; an update that cannot reach it fails explicitly. Existing child work is retained. |
| DescribeExecution | Executions | Supported | Common | Returns Standard execution status, input, output, failure and redrive details through the adapter's execution record. |
| GetExecutionHistory | Executions | Supported | Most usage | Returns Step Functions events in causal order, including event links and timestamps; Temporal history is translated into the public event model. Express has no API history. |
| ListExecutions | Executions | Supported | Common | Lists Standard executions by state machine or Map Run, with status filters and pagination. |
| RedriveExecution | Executions | Supported | Most usage | Resumes eligible unsuccessful Standard work under the same execution identity and revision within the redrive window; successful states are retained and rerun states reset their retry counters. |
| StartExecution | Executions | Supported | Common | Admits a Standard execution durably and runs the selected ASL revision as a Temporal workflow. Standard name/input deduplication is kept; Express uses a separate short-lived execution path and fresh starts are not deduplicated. |
| StartSyncExecution | Executions | Supported | Most usage | Returns the result of an Express execution within its five-minute limit, including execution failures in the response body; caller disconnection does not cancel accepted work. |
| StopExecution | Executions | Supported | Common | Stops the Standard workflow and records ABORTED with the supplied error and cause; cancellation of an already accepted external effect depends on its integration. |
| CreateStateMachine | State machines | Supported | Common | Validates ASL and stores the definition, role, mode, encryption, logging and tags; unsupported integrations are rejected. |
| DeleteStateMachine | State machines | Supported | Common | Reports DELETING, terminates executions at their next state transition and retires the definition, versions and aliases once executions have closed. Express deletion is eventually consistent. |
| DescribeStateMachine | State machines | Supported | Common | Returns the adapter's definition, role, mode, revision and configuration. |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | Returns the immutable definition and revision selected for a Standard execution. |
| ListStateMachines | State machines | Supported | Common | Lists state machines using opaque pagination tokens. |
| UpdateStateMachine | State machines | Supported | Common | Creates a new revision for subsequent executions; active executions retain their selected definition and runtime version. |
| ListTagsForResource | Tags | Supported | Full surface | Returns the resource's tags. |
| TagResource | Tags | Supported | Full surface | Attaches tags to state-machine or Activity records. |
| UntagResource | Tags | Supported | Full surface | Removes tags from the adapter's resource record. |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | Stores weighted routing to one or two versions; each new execution retains the selected version. |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | Deletes the alias without interrupting executions previously started through it. |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | Deletes an unreferenced version; a version used by an alias cannot be deleted. |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | Returns the alias and routing configuration. |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | Lists aliases with pagination. |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | Lists published versions with pagination. |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | Publishes an immutable numbered revision. |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | Updates routing for subsequent starts; existing executions keep their selected version. |
#### How Step Functions uses Temporal Cloud
Your application keeps using the Step Functions API in the target environment. A Tensor9 service adapter stores definitions, revisions, versions and aliases, then starts Standard executions in a Temporal Cloud namespace owned by the customer. Tensor9-maintained interpreter workers run beside the adapter in the deployment environment and evaluate the original Amazon States Language definition.
Temporal operates the workflow service and stores execution history in the namespace's selected region. The workers execute the orchestration code and service calls. Temporal Cloud does not host these workers. An Express execution follows the adapter's separate, short-lived execution path.
#### Connecting the namespace
Connect an existing customer-owned namespace using its full namespace ID, endpoint and an authorized credential. The initial connection uses mutual TLS. Namespace creation, billing and account administration remain with the customer; deploying or removing the adapter does not create or delete that namespace.
The workers need network access to Temporal Cloud and to the service adapters used by Tasks. An application on Azure, GCP, Kubernetes or OCI can use the namespace independently of where its managed history is stored. Select the namespace region and connectivity to meet the deployment's residency requirements. This option requires access to the managed service and does not serve a disconnected deployment.
#### An execution waiting for approval
StartExecution returns an AWS execution ARN while the Standard workflow runs. The interpreter uses Temporal timers for Wait states, activities for external calls, and child workflows for Parallel branches and Map items. ASL Retry and Catch determine the business attempts; the integration adapter resolves ambiguous service responses under its own idempotency rules.
For an approval task using .waitForTaskToken, an authorized callback reaches the Step Functions adapter in the deployment environment. The adapter records completion for the exact active attempt and delivers it to the workflow in Temporal Cloud. The caller receives success only after the task disposition is durable. An engine notification alone is insufficient.
If a worker restarts during the wait, a compatible worker resumes from Temporal's history. The execution keeps its AWS identity, selected definition and worker version. Moving the deployment to a different engine affects subsequent starts and does not move this active approval.
#### Limitations
Where Step Functions and Temporal Cloud differ
* **Managed history leaves the deployment environment.** Temporal Cloud stores workflow history and any encoded payloads in the selected namespace region. Payload encryption does not move that storage into the local cluster; avoid secrets in searchable metadata.
* **The namespace does not provide AWS integrations.** A Task Resource must resolve to a supported service operation and invocation pattern in the deployment. .sync and callback behavior depend on that integration.
* **Service capacity and worker capacity both matter.** Namespace limits, history size, worker slots and downstream service limits affect throughput. Selecting Temporal Cloud does not reserve concurrency for every Map item.
* **Debugging uses Temporal's interface.** Temporal Web UI exposes workflow history and pending work rather than the AWS console's visual ASL graph. Payload decoding requires authorized access. Logs use the deployment's logging destination; X-Ray tracing is rejected when enabled.
* **Express restrictions remain.** Express executions have no Standard execution-history API and cannot use Activities, Distributed Map, .sync or .waitForTaskToken.
#### Other considerations
* **Responsibility and cost.** Temporal operates the managed service. The customer owns the account, namespace, credentials and billing. Tensor9 maintains the service adapter and interpreter workers, whose compute still runs in the deployment environment.
* **Retention and encryption.** Set namespace retention together with the adapter's history and redrive retention requirements. Configure the worker payload codec and key access when using customer-managed encryption. Web UI access and permission to decode payloads are separate controls.
* **Cutover.** Deploy definitions, versions and aliases through the adapter. Existing AWS executions finish there; active executions, outstanding tokens and historical runs are not imported into Temporal Cloud.
* **Connection lifecycle.** Rotate namespace credentials while retaining access for existing executions. An adapter removal releases its connection and owned workers, leaving the customer's namespace and unrelated workflows intact.
See Temporal's [namespace and region configuration](https://docs.temporal.io/cloud/namespaces), [worker architecture](https://docs.temporal.io/encyclopedia/architecture/temporal-sdks) and [Web UI documentation](https://docs.temporal.io/web-ui).
## On Azure
### Via Azure Durable Functions
| Capability | Area | Support | Required tier | Operations | Notes |
| ----------------------------- | ---------------------- | ------------ | ------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Data flow and expressions | Amazon States Language | Supported | - | - | InputPath, Parameters, ResultSelector, ResultPath, OutputPath, intrinsic functions, JSONata, variables and Assign are evaluated by the orchestrator |
| Distributed Map | Amazon States Language | Supported | - | - | a Map Run fans out into child orchestrations within MaxConcurrency; item slots and ordered output survive a worker restart, an item retry never becomes a whole-Map retry, and UpdateMapRun reaches children already running or fails with a named error. A large Map Run is paced by shared admission and backpressure without any change to its semantics |
| Error handling | Amazon States Language | Supported | - | - | Retry and Catch with backoff, jitter and error matching; a retried attempt is one explicit attempt and is never multiplied by the platform's own retry |
| Parallel and inline Map | Amazon States Language | Supported | - | - | branches and items run as child orchestrations and their outputs are aggregated in order |
| Wait states and timeouts | Amazon States Language | Supported | - | - | a Wait is a durable timer held as a scheduled message in the task hub, whether it lasts seconds or months; state and execution timeouts fire as States.Timeout |
| Encryption configuration | Configuration | Supported | - | - | a customer-managed key names a key served by the KMS mapping on the same appliance (Key Vault on Azure); definitions and execution payloads are encrypted under it and become unreadable when it is revoked |
| Logging configuration | Configuration | Partial | - | - | includeExecutionData decides whether execution payloads are written at all, and the configured destination decides whose log they reach; the destination is served by the appliance's logging, since CloudWatch Logs is a service the appliance does not adapt |
| Tracing configuration | Configuration | Out of scope | - | - | X-Ray is not adapted, so a configuration that enables tracing is rejected at CreateStateMachine and UpdateStateMachine rather than stored and ignored |
| EXPRESS workflows | Execution model | Supported | - | - | an Express execution is an inline run in the adapter with no durable record, within the 5-minute ceiling; as on AWS it has no history through the API, cannot use Activities, Distributed Map, .sync or .waitForTaskToken, and DescribeStateMachineForExecution, GetExecutionHistory, ListExecutions, RedriveExecution and StopExecution refuse it. A fresh Express start is never deduplicated, and an interrupted delivery is retried under the same accepted start |
| STANDARD workflows | Execution model | Supported | - | - | exactly-once execution with a durable record, up to one year |
| Service integrations | Integrations | Partial | - | - | a Task Resource naming an AWS service is served by that service's mapping on the same appliance, including the .sync and .waitForTaskToken patterns, nested executions and Task.Credentials role overrides; a Resource naming a service the appliance does not serve is refused at CreateStateMachine |
| Payload and definition limits | Limits | Supported | - | - | the 256 KiB ceiling on inputs, outputs and state payloads and the 1 MB definition ceiling are enforced at the API, so a definition that fits on AWS fits here |
| Operation | Area | Support | Depth | Notes |
| -------------------------------- | -------------------- | -------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| CreateActivity | Activities | Adapter-served | Most usage | an Activity is a record and a task queue the adapter itself serves, since Azure has no resource that an outside worker long-polls by name |
| DeleteActivity | Activities | Adapter-served | Full surface | deletes the Activity even while workers hold tasks from it, as on AWS; a worker's next SendTaskSuccess for such a task answers TaskDoesNotExist |
| DescribeActivity | Activities | Adapter-served | Full surface | returns the Activity's ARN, name and creation date |
| GetActivityTask | Activities | Adapter-served | Most usage | holds the poll open for up to 60 seconds and hands one task to one worker with a task token the adapter mints; an empty poll returns a null token, so workers keep the 65-second socket timeout AWS recommends |
| ListActivities | Activities | Adapter-served | Full surface | lists the Activities |
| SendTaskFailure | Activities | Adapter-served | Most usage | fails the task with the error and cause supplied |
| SendTaskHeartbeat | Activities | Adapter-served | Full surface | renews the task's heartbeat window; a task whose heartbeat lapses fails with States.Timeout |
| SendTaskSuccess | Activities | Adapter-served | Most usage | completes the task the token identifies, once; a stale or unknown token is refused |
| TestState | Diagnostics | Supported | Full surface | runs a single state through the same evaluator without starting an execution; a Task state that reaches a real service does so under the caller's own authorization |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | validates a definition without creating anything and returns the diagnostics with their severity; a Task whose Resource names a service the appliance does not serve is reported here |
| DescribeMapRun | Distributed Map | Supported | Most usage | returns the Map Run's status, item counts, tolerated-failure settings and concurrency |
| ListMapRuns | Distributed Map | Supported | Full surface | lists the Map Runs of an execution |
| UpdateMapRun | Distributed Map | Supported | Full surface | changes MaxConcurrency or the tolerated-failure thresholds of a running Map Run; child runs already in flight continue |
| DescribeExecution | Executions | Supported | Common | returns status, input, output, error, cause and redrive details for the execution |
| GetExecutionHistory | Executions | Supported | Most usage | returns the execution's transitions as Step Functions events with ids, previous-event ids and timestamps in causal order, derived from the orchestration's record; EXPRESS executions have no history through the API, as on AWS |
| ListExecutions | Executions | Supported | Common | lists executions by state machine or Map Run, filtered by status and redrive filter, with opaque pagination tokens |
| RedriveExecution | Executions | Supported | Most usage | resumes a failed, aborted or timed-out STANDARD execution from its unsuccessful states within 14 days of closing, under the same execution ARN and revision; successful states are not rerun, retry counters on the rerun states reset, and on a Distributed Map only the failed child runs restart |
| StartExecution | Executions | Supported | Common | admits the execution, pins its revision and returns while it runs: a STANDARD execution as a Durable Functions orchestration, an EXPRESS execution as an inline run with no durable record. A STANDARD start with the name and input of a running execution returns the original response; a closed execution or a different input returns ExecutionAlreadyExists, and a name is reusable 90 days after it closes. EXPRESS starts are never deduplicated |
| StartSyncExecution | Executions | Supported | Most usage | the synchronous result API of an EXPRESS state machine: the request is held open until the inline run completes or the 5-minute ceiling passes, a failed run is reported in the response body, and a caller that disconnects does not cancel accepted work |
| StopExecution | Executions | Supported | Common | terminates the orchestration and records the ABORTED outcome with the error and cause supplied |
| CreateStateMachine | State machines | Supported | Common | validates the Amazon States Language definition and records the state machine with its role, type, encryption, logging and tags; the definition is kept as written and interpreted at run time, so nothing is rewritten by hand |
| DeleteStateMachine | State machines | Supported | Common | succeeds at once and the state machine reads DELETING; it is retired when its running executions have completed, and its versions and aliases are retired with it |
| DescribeStateMachine | State machines | Supported | Common | returns the definition, role, type, revision and configuration from the adapter's record |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | returns the exact definition and revision an execution runs, which is pinned when the execution starts |
| ListStateMachines | State machines | Supported | Common | lists state machines with opaque pagination tokens |
| UpdateStateMachine | State machines | Supported | Common | replaces the definition, role or configuration and returns a new revision; executions already running keep the revision they started on |
| ListTagsForResource | Tags | Supported | Full surface | lists the tags on a state machine or Activity |
| TagResource | Tags | Supported | Full surface | attaches tags to a state machine or Activity |
| UntagResource | Tags | Supported | Full surface | removes tags |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | an alias routes to one or two versions by weight; an execution started through the alias pins the version it was routed to |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | deletes the alias; executions it routed keep running |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | deletes a version; refused while an alias still routes to it, as on AWS |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | returns the alias and its routing configuration |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | lists the aliases of a state machine |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | lists the published versions |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | publishes the current revision as an immutable numbered version |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | changes the routing for executions started afterwards; running executions are unaffected |
#### How it works
Your application keeps calling the Step Functions API. In the target environment those calls reach a Tensor9 service adapter instead of AWS. The adapter holds each state machine as a record: the Amazon States Language definition as you wrote it, the execution role, the type, the versions, the aliases and the tags. It answers every `states:` operation from that record and from the executions it has admitted.
A Standard execution is a Durable Functions orchestration instance; an Express execution runs inline in the adapter and leaves no durable record, as on AWS. StartExecution admits the execution, pins the revision it will run, and for a Standard execution hands it to an orchestrator function that Tensor9 maintains and deploys into an Azure Functions app in the target environment. That orchestrator is generic: it interprets the definition state by state, so a state machine is never rewritten into orchestrator code and an UpdateStateMachine deploys nothing. Durable timers serve Wait states, activity functions serve Task states, sub-orchestrations serve Parallel branches and Map items, and external events serve callbacks and task tokens; StopExecution terminates the instance. Durable Functions checkpoints the orchestration's progress in its task hub, so an execution survives a restart of the function app or of the adapter and resumes where it left off. GetExecutionHistory returns Step Functions events built from that record in causal order; the platform's own replay events are not part of it.
A Task state's Resource names an AWS service, and it is served by that service's mapping on the same appliance: a Lambda ARN invokes the function the Lambda mapping runs, an SQS or SNS integration reaches the queue or topic served there, and a `.waitForTaskToken` integration parks the orchestration on an external event until SendTaskSuccess or SendTaskFailure arrives. Each Task effect is authorized against the state machine's execution role, or the Task.Credentials role where one is set, before it is made, and the call itself travels on the appliance's own identity; no AWS credential is involved.
#### Azure resources behind a deployment
Two Azure resources sit behind a Step Functions deployment: a function app on a Premium plan, which gives the orchestrator always-ready instances and virtual-network access, and a storage account whose task hub holds orchestration history and queued work. Both are owned in the target environment. Tensor9 deploys its orchestrator code into the function app and upgrades it, and removing a backend selection never deletes the function app or the storage account.
In the Azure portal you see orchestration instances named by the adapter, activity invocations, and the storage account's queues and tables. State machines, executions and ARNs are not Azure resources; they exist in the adapter's record and are what the Step Functions API returns, so DescribeExecution, ListExecutions and GetExecutionHistory are the way to observe an execution, exactly as on AWS.
#### Limitations
* **Activities are served by the adapter.** Azure has no resource that a worker outside the platform long-polls by name, so an Activity is a queue the adapter itself serves: GetActivityTask holds the poll open for up to 60 seconds, the task token is minted by the adapter, and SendTaskSuccess, SendTaskFailure and SendTaskHeartbeat are checked against it. Workers need no code change; they must reach the adapter's endpoint. - **Large Map Runs are paced by the appliance.** A Map Run becomes N child orchestrations within MaxConcurrency, and a large one is admitted with backpressure rather than all at once; its semantics do not change. An UpdateMapRun that cannot reach children already running fails with a named error instead of reporting a change that did not happen. - **Logs and traces do not reach CloudWatch or X-Ray.** `includeExecutionData` decides whether execution payloads are written at all and the configured destination decides whose log they reach; the destination is served by the appliance's logging, since CloudWatch Logs is a service the appliance does not adapt. A `tracingConfiguration` that enables X-Ray tracing is rejected at CreateStateMachine and UpdateStateMachine, because X-Ray is not adapted and a setting that is stored but ignored would misreport what runs. - **Service integrations are bounded by the appliance.** A Task state reaches the services adapted on the same appliance. A Resource naming a service the appliance does not serve is reported by ValidateStateMachineDefinition and refused at CreateStateMachine with an error naming the state; a definition is never admitted only to fail on its first execution. - **The engine choice is fixed per execution.** Which engine runs a state machine is chosen per deployment and recorded with each execution. Changing it affects executions started afterwards; executions already running, their history and their outstanding task tokens stay on the engine they started on until they complete and their retention expires. Nothing migrates a live execution.
#### Other considerations
* **Migration.** State machines are created by your own deployment: applying your Step Functions resources against the adapter creates them through CreateStateMachine, versions and aliases included. Executions do not migrate. One started on AWS completes on AWS, one started after cutover runs on Azure, and AWS execution history is not copied. - **Who operates what.** The function app and the storage account are owned in the target environment and operated by Microsoft. Tensor9 maintains the orchestrator code deployed into the function app, upgrades it, and operates the adapter; an upgrade keeps in-flight orchestrations on the orchestrator version they started with, so a running execution is not replayed against changed code. - **Cost shape.** AWS bills a Standard execution per state transition and an Express one per run, duration and memory. On Azure the cost is the Premium plan's instances, which run whether or not executions are in flight, plus storage transactions on the task hub. - **Durability.** Orchestration state lives in the storage account; the adapter's own record of state machines, versions, aliases and Activities lives in the appliance's durable store. Both are in the target environment.
## State-machine administration
The state-machine API manages definitions, versions, aliases and configuration. The target-specific sections below describe these administration operations alongside the execution behavior documented above.
### On Google Cloud
#### Via Cloud Workflows
| Capability | Area | Support | Required tier | Operations | Notes |
| ------------------------ | ------------- | ------------ | ------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| Encryption configuration | Configuration | Supported | - | - | a customer-managed key names a key served by the KMS mapping on the same appliance |
| Logging configuration | Configuration | Partial | - | - | includeExecutionData and the configured destination are honoured; the destination is served by the appliance, since CloudWatch Logs is not adapted |
| Tracing configuration | Configuration | Out of scope | - | - | X-Ray is not adapted, so a configuration that enables tracing is rejected |
| Definition limit | Limits | Supported | - | - | the 1 MB definition ceiling is enforced at the API; a definition is split across prepared modules because one Workflows source is capped at 128 KB |
| Operation | Area | Support | Depth | Notes |
| ------------------------------ | -------------- | --------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| CreateStateMachineAlias | Aliases | Supported | Most usage | weighted routing across up to two of this machine's versions, held by the adapter |
| DeleteStateMachineAlias | Aliases | Supported | Most usage | - |
| DescribeStateMachineAlias | Aliases | Supported | Most usage | - |
| ListStateMachineAliases | Aliases | Supported | Most usage | - |
| UpdateStateMachineAlias | Aliases | Supported | Most usage | - |
| CreateStateMachine | State machines | Supported | Common | stores the definition, role, type and configuration as revision one and prepares its workflow modules; a state or field the translation cannot carry is refused here rather than dropped |
| DeleteStateMachine | State machines | Supported | Common | succeeds immediately and the state machine reads DELETING until running executions finish |
| DescribeStateMachine | State machines | Supported | Common | reads the record; a version or alias ARN reads that revision's definition |
| ListStateMachines | State machines | Supported | Common | - |
| UpdateStateMachine | State machines | Supported | Common | produces the next revision and prepares new modules; running executions keep the modules they started on |
| ValidateStateMachineDefinition | State machines | Supported | Common | the shared ASL validator, plus this engine's own refusals for states it does not run |
| ListTagsForResource | Tags | Supported | Full surface | - |
| TagResource | Tags | Supported | Full surface | - |
| UntagResource | Tags | Supported | Full surface | - |
| DeleteStateMachineVersion | Versions | Supported | Most usage | refused while an alias routes to it |
| DescribeStateMachineVersion | Versions | Supported | Most usage | - |
| ListStateMachineVersions | Versions | Supported | Most usage | - |
| PublishStateMachineVersion | Versions | Supported | Most usage | an immutable version of the current revision, held by the adapter |
##### The state machine as an adapter record, prepared per revision
CreateStateMachine stores the definition, role, type, encryption, logging and tags as one revision and prepares that revision's Cloud Workflows modules. UpdateStateMachine produces the next revision and prepares its own modules; nothing already prepared is changed, so an execution keeps running the modules it started on. DeleteStateMachine succeeds immediately and the state machine reads DELETING; it is retired once its running executions complete.
##### Limitations
* **A state the translation cannot carry is refused, not dropped.** The engine keeps its own list of runnable state types and refused fields and applies it at CreateStateMachine and ValidateStateMachineDefinition, because a workflow that silently omitted a state would run to a different answer than the one asked for. - **Tracing cannot be enabled.** X-Ray is not adapted, so a `tracingConfiguration` that enables tracing is rejected at CreateStateMachine and UpdateStateMachine. - **Logs stay on the appliance.** `includeExecutionData` and the configured destination are honoured; the destination is served by the appliance, since CloudWatch Logs is not adapted. - **A Task Resource must name a served service.** ValidateStateMachineDefinition reports, and CreateStateMachine refuses, a Resource naming a service this appliance does not adapt.
##### Other considerations
Cloud Workflows creates a new workflow revision only when a workflow's source or service account changes, and every execution records the revision it is using. The adapter relies on exactly that: a Step Functions version or alias maps onto prepared modules that are never edited in place, so AWS's immutable-version guarantee holds without Cloud Workflows needing an alias concept of its own.
### On Google Cloud, Azure, OCI, and Private Kubernetes
#### Via Temporal (Self-Hosted)
| Capability | Area | Support | Required tier | Operations | Notes |
| ---------------------- | ------------- | ------------ | ------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------ |
| Logging configuration | Configuration | Partial | - | - | Configured logs use the deployment's logging destination and honor includeExecutionData; CloudWatch Logs is not carried. |
| Tracing configuration | Configuration | Out of scope | - | - | Enabling X-Ray tracing is rejected when creating or updating a state machine. |
| Integration validation | Definitions | Partial | - | - | Definitions can use only the deployment's supported Task resources and invocation patterns. |
| Operation | Area | Support | Depth | Notes |
| -------------------------------- | -------------------- | --------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | Validates ASL without creating a resource and reports diagnostics, including unsupported Task resources and invocation patterns. |
| CreateStateMachine | State machines | Supported | Common | Validates ASL and stores the definition, role, mode, encryption, logging and tags; unsupported integrations are rejected. |
| DeleteStateMachine | State machines | Supported | Common | Reports DELETING, terminates executions at their next state transition and retires the definition, versions and aliases once executions have closed. Express deletion is eventually consistent. |
| DescribeStateMachine | State machines | Supported | Common | Returns the adapter's definition, role, mode, revision and configuration. |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | Returns the immutable definition and revision selected for a Standard execution. |
| ListStateMachines | State machines | Supported | Common | Lists state machines using opaque pagination tokens. |
| UpdateStateMachine | State machines | Supported | Common | Creates a new revision for subsequent executions; active executions retain their selected definition and runtime version. |
| ListTagsForResource | Tags | Supported | Full surface | Returns the resource's tags. |
| TagResource | Tags | Supported | Full surface | Attaches tags to state-machine or Activity records. |
| UntagResource | Tags | Supported | Full surface | Removes tags from the adapter's resource record. |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | Stores weighted routing to one or two versions; each new execution retains the selected version. |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | Deletes the alias without interrupting executions previously started through it. |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | Deletes an unreferenced version; a version used by an alias cannot be deleted. |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | Returns the alias and routing configuration. |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | Lists aliases with pagination. |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | Lists published versions with pagination. |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | Publishes an immutable numbered revision. |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | Updates routing for subsequent starts; existing executions keep their selected version. |
##### A definition shared by interpreter workers
A Step Functions state machine is a record in the Tensor9 service adapter: its ASL definition, execution role, mode and configuration. Creating it does not create a Temporal workflow type or a new Temporal cluster. The interpreter workers are shared; a Standard execution reads the immutable revision selected when it starts.
UpdateStateMachine changes subsequent executions. Published versions retain their definitions, and an alias selects a version by weight for each new execution. DeleteStateMachine reports DELETING and terminates executions at their next state transition. It retires the state machine, versions and aliases once executions have closed; Express deletion is eventually consistent.
##### Limitations
Where the Step Functions state-machine mapping differs
* **A definition needs supported integrations.** ValidateStateMachineDefinition reports unsupported Task resources; CreateStateMachine rejects them. Enabling X-Ray tracing is also rejected.
* **The record is outside Temporal's configuration model.** Temporal Web UI shows executions and their history. DescribeStateMachine and the versions and aliases APIs read the adapter's records.
##### Other considerations
* **Durability.** Protect the adapter's configuration records as well as the self-hosted Temporal database. Restoring only one does not restore the full service.
* **Deployment.** Apply state-machine resources and publish versions through the Step Functions endpoint. No workflow-specific worker code is handed to your team.
* **Operations.** The deployment operator maintains the Temporal cluster and backups; Tensor9 maintains the adapter and interpreter. The parent Step Functions profile describes execution, callback and capacity behavior.
#### Via Temporal Cloud (Managed)
| Capability | Area | Support | Required tier | Operations | Notes |
| ---------------------- | ------------- | ------------ | ------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------ |
| Logging configuration | Configuration | Partial | - | - | Configured logs use the deployment's logging destination and honor includeExecutionData; CloudWatch Logs is not carried. |
| Tracing configuration | Configuration | Out of scope | - | - | Enabling X-Ray tracing is rejected when creating or updating a state machine. |
| Integration validation | Definitions | Partial | - | - | Definitions can use only the deployment's supported Task resources and invocation patterns. |
| Operation | Area | Support | Depth | Notes |
| -------------------------------- | -------------------- | --------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | Validates ASL without creating a resource and reports diagnostics, including unsupported Task resources and invocation patterns. |
| CreateStateMachine | State machines | Supported | Common | Validates ASL and stores the definition, role, mode, encryption, logging and tags; unsupported integrations are rejected. |
| DeleteStateMachine | State machines | Supported | Common | Reports DELETING, terminates executions at their next state transition and retires the definition, versions and aliases once executions have closed. Express deletion is eventually consistent. |
| DescribeStateMachine | State machines | Supported | Common | Returns the adapter's definition, role, mode, revision and configuration. |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | Returns the immutable definition and revision selected for a Standard execution. |
| ListStateMachines | State machines | Supported | Common | Lists state machines using opaque pagination tokens. |
| UpdateStateMachine | State machines | Supported | Common | Creates a new revision for subsequent executions; active executions retain their selected definition and runtime version. |
| ListTagsForResource | Tags | Supported | Full surface | Returns the resource's tags. |
| TagResource | Tags | Supported | Full surface | Attaches tags to state-machine or Activity records. |
| UntagResource | Tags | Supported | Full surface | Removes tags from the adapter's resource record. |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | Stores weighted routing to one or two versions; each new execution retains the selected version. |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | Deletes the alias without interrupting executions previously started through it. |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | Deletes an unreferenced version; a version used by an alias cannot be deleted. |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | Returns the alias and routing configuration. |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | Lists aliases with pagination. |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | Lists published versions with pagination. |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | Publishes an immutable numbered revision. |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | Updates routing for subsequent starts; existing executions keep their selected version. |
##### State machines connected to a customer-owned namespace
The Tensor9 service adapter stores each state machine's ASL definition, execution role, mode and configuration. The customer supplies an existing Temporal Cloud namespace. Creating a state machine records a definition; it does not create a namespace or transfer account ownership.
Published versions are immutable adapter records. Aliases route new executions across versions, and each execution retains its selected revision. Updating a state machine does not change active executions. Deletion terminates executions at their next state transition and retires the definition, versions and aliases after they close. Express deletion is eventually consistent. The Temporal Cloud namespace remains intact.
##### Limitations
Where the Step Functions state-machine mapping differs
* **Namespace settings are separate.** State-machine APIs do not configure Temporal Cloud regions, retention, account permissions or billing. Configure these when connecting the deployment.
* **Integration and telemetry restrictions apply.** Definitions must use the service integrations available in the deployment. X-Ray tracing is rejected when enabled, and logs use the deployment's logging destination.
##### Other considerations
* **Stored definitions and managed history.** Definitions, versions and aliases live in the adapter's durable records; Temporal Cloud holds native execution history in the selected namespace region. Preserve both for their respective retention obligations.
* **Ownership.** The customer controls the namespace and its credentials. Tensor9 maintains the adapter and interpreter workers in the deployment environment; Temporal operates the managed workflow service.
* **Migration.** Recreate definitions and versions through the Step Functions API. Existing execution state, history and outstanding callback tokens remain with their original service.
### On Azure
#### Via Azure Durable Functions
| Capability | Area | Support | Required tier | Operations | Notes |
| ------------------------ | ------------- | ------------ | ------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Encryption configuration | Configuration | Supported | - | - | a customer-managed key names a key served by the KMS mapping on the same appliance (Key Vault on Azure); the definition and execution payloads are encrypted under it and become unreadable when it is revoked |
| Logging configuration | Configuration | Partial | - | - | includeExecutionData and the configured destination are honoured; the destination is served by the appliance's logging, since CloudWatch Logs is a service the appliance does not adapt |
| Tracing configuration | Configuration | Out of scope | - | - | X-Ray is not adapted, so a configuration that enables tracing is rejected rather than stored and ignored |
| Definition limit | Limits | Supported | - | - | the 1 MB definition ceiling is enforced at the API |
| Operation | Area | Support | Depth | Notes |
| -------------------------------- | -------------------- | --------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ValidateStateMachineDefinition | Diagnostics | Supported | Most usage | validates a definition without creating anything and returns diagnostics with severity |
| CreateStateMachine | State machines | Supported | Common | validates the definition and records the state machine with its role, type, encryption, logging and tags; the definition is stored as written, since it is interpreted at run time rather than translated |
| DeleteStateMachine | State machines | Supported | Common | succeeds at once and the state machine reads DELETING until its running executions complete; versions and aliases are retired with it |
| DescribeStateMachine | State machines | Supported | Common | returns the definition, role, type, revision and configuration |
| DescribeStateMachineForExecution | State machines | Supported | Most usage | returns the definition and revision pinned by a given execution |
| ListStateMachines | State machines | Supported | Common | lists state machines with opaque pagination tokens |
| UpdateStateMachine | State machines | Supported | Common | replaces the definition, role or configuration and returns a new revision; executions in flight keep the revision they started on |
| ListTagsForResource | Tags | Supported | Full surface | lists the tags |
| TagResource | Tags | Supported | Full surface | attaches tags to the state machine |
| UntagResource | Tags | Supported | Full surface | removes tags |
| CreateStateMachineAlias | Versions and aliases | Supported | Most usage | an alias routes to one or two versions by weight |
| DeleteStateMachineAlias | Versions and aliases | Supported | Full surface | deletes the alias |
| DeleteStateMachineVersion | Versions and aliases | Supported | Full surface | deletes a version; refused while an alias still routes to it |
| DescribeStateMachineAlias | Versions and aliases | Supported | Full surface | returns the alias and its routing |
| ListStateMachineAliases | Versions and aliases | Supported | Full surface | lists the aliases |
| ListStateMachineVersions | Versions and aliases | Supported | Most usage | lists the published versions |
| PublishStateMachineVersion | Versions and aliases | Supported | Most usage | publishes the current revision as an immutable numbered version |
| UpdateStateMachineAlias | Versions and aliases | Supported | Full surface | changes the routing for executions started afterwards |
##### The state machine as an adapter record
CreateStateMachine stores the definition, role, type, encryption, logging and tags as one revision. UpdateStateMachine produces the next revision, and an execution pins the revision it starts on, so a definition change never alters a run in flight. PublishStateMachineVersion freezes a revision as a numbered version and an alias routes new executions across one or two versions by weight, exactly as on AWS.
DeleteStateMachine succeeds immediately and the state machine reads DELETING; it is retired once its running executions complete, and its versions and aliases go with it. No Azure resource is created or removed by any of these calls: the orchestrator function app is shared by every state machine on the appliance and reads the record at run time.
##### Limitations
* **Tracing cannot be enabled.** X-Ray is not adapted, so a `tracingConfiguration` that enables tracing is rejected at CreateStateMachine and UpdateStateMachine rather than stored and ignored. - **Logs stay on the appliance.** `includeExecutionData` and the configured destination are honoured; the destination is served by the appliance's logging, since CloudWatch Logs is a service the appliance does not adapt. - **A Task Resource must name a served service.** ValidateStateMachineDefinition reports, and CreateStateMachine refuses, a Resource naming a service the appliance does not serve. Run-time limits (Express semantics, Activities, Distributed Map fan-out) are on the Step Functions card for Azure Durable Functions.
## Service level agreements
These tables show Tensor9's standard service levels and adapters whose standard terms are still being defined. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider's own SLA. Each origin-to-target pair has its own terms or an explicit pending status.
See the [SLA tables](/byoc/support/service-adapter-slas), [measurement rules](/byoc/support/service-levels), and [scaling conditions](/byoc/support/scaling-and-limits).
### Step Functions to Azure Durable Functions
| SLA | Service level | What is covered | Conditions |
| ------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workflow and execution reads | 8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation | 15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Execution and task coordination | 12 ms monthly p99 | `aws::1.0.0::sfn`: `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun` | Payload at most 256 KiB; one execution/task token; customer task execution excluded. |
| Activity poll processing | 5 ms monthly p99 | `aws::1.0.0::sfn`: `GetActivityTask` | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. |
| Bounded synchronous workflow processing | 25 ms monthly p99 | `aws::1.0.0::sfn`: `StartSyncExecution` | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. |
| Correct request handling | 99.9% per calendar month | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.
**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
#### What this adapter does
Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or azure::1.0.0::durable-functions. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.
#### How the latency targets were chosen
**Workflow and execution reads: 8 ms monthly p99.** `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.
**Definition, version, alias and tag mutation: 15 ms monthly p99.** `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.
**Execution and task coordination: 12 ms monthly p99.** `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`. Durable transition admission and bounded workflow evaluation.
**Activity poll processing: 5 ms monthly p99.** `GetActivityTask`. Authorization, bounded task lookup and response conversion around the documented long poll.
**Bounded synchronous workflow processing: 25 ms monthly p99.** `StartSyncExecution`. Durable admission, bounded transition evaluation and final response conversion.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
#### What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.
For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.
#### Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy.
With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.
#### Scaling and target-service capacity
Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.
Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.
#### Data and behavior guarantees
Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
#### Example and diagnosis
StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.
Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
### Step Functions to Cloud Workflows
| SLA | Service level | What is covered | Conditions |
| ------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workflow and execution reads | 8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation | 15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Execution and task coordination | 12 ms monthly p99 | `aws::1.0.0::sfn`: `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun` | Payload at most 256 KiB; one execution/task token; customer task execution excluded. |
| Activity poll processing | 5 ms monthly p99 | `aws::1.0.0::sfn`: `GetActivityTask` | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. |
| Bounded synchronous workflow processing | 25 ms monthly p99 | `aws::1.0.0::sfn`: `StartSyncExecution` | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. |
| Correct request handling | 99.9% per calendar month | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.
**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
#### What this adapter does
Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or google::1.0.0::workflows. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.
#### How the latency targets were chosen
**Workflow and execution reads: 8 ms monthly p99.** `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.
**Definition, version, alias and tag mutation: 15 ms monthly p99.** `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.
**Execution and task coordination: 12 ms monthly p99.** `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`. Durable transition admission and bounded workflow evaluation.
**Activity poll processing: 5 ms monthly p99.** `GetActivityTask`. Authorization, bounded task lookup and response conversion around the documented long poll.
**Bounded synchronous workflow processing: 25 ms monthly p99.** `StartSyncExecution`. Durable admission, bounded transition evaluation and final response conversion.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
#### What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.
For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.
#### Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy.
With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.
#### Scaling and target-service capacity
Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.
Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.
#### Data and behavior guarantees
Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
#### Example and diagnosis
StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.
Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
### Step Functions to Temporal Cloud (Managed)
| SLA | Service level | What is covered | Conditions |
| ------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workflow and execution reads | 8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation | 15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Execution and task coordination | 12 ms monthly p99 | `aws::1.0.0::sfn`: `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun` | Payload at most 256 KiB; one execution/task token; customer task execution excluded. |
| Activity poll processing | 5 ms monthly p99 | `aws::1.0.0::sfn`: `GetActivityTask` | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. |
| Bounded synchronous workflow processing | 25 ms monthly p99 | `aws::1.0.0::sfn`: `StartSyncExecution` | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. |
| Correct request handling | 99.9% per calendar month | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.
**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
#### What this adapter does
Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or temporalio::1.0.0::managed. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.
#### How the latency targets were chosen
**Workflow and execution reads: 8 ms monthly p99.** `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.
**Definition, version, alias and tag mutation: 15 ms monthly p99.** `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.
**Execution and task coordination: 12 ms monthly p99.** `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`. Durable transition admission and bounded workflow evaluation.
**Activity poll processing: 5 ms monthly p99.** `GetActivityTask`. Authorization, bounded task lookup and response conversion around the documented long poll.
**Bounded synchronous workflow processing: 25 ms monthly p99.** `StartSyncExecution`. Durable admission, bounded transition evaluation and final response conversion.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
#### What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.
For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.
#### Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy.
With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.
#### Scaling and target-service capacity
Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.
Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.
#### Data and behavior guarantees
Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
#### Example and diagnosis
StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.
Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
### Step Functions to Temporal (Self-Hosted)
| SLA | Service level | What is covered | Conditions |
| ------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workflow and execution reads | 8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation | 15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Execution and task coordination | 12 ms monthly p99 | `aws::1.0.0::sfn`: `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun` | Payload at most 256 KiB; one execution/task token; customer task execution excluded. |
| Activity poll processing | 5 ms monthly p99 | `aws::1.0.0::sfn`: `GetActivityTask` | Adapter processing before the poll and after task availability; intentional wait time is excluded and reported separately. |
| Bounded synchronous workflow processing | 25 ms monthly p99 | `aws::1.0.0::sfn`: `StartSyncExecution` | Payload at most 256 KiB and at most 32 workflow transitions; customer-service execution and intentional waits excluded by observed spans. |
| Correct request handling | 99.9% per calendar month | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`, `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`, `GetActivityTask`, `StartSyncExecution` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.
**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
#### What this adapter does
Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or temporalio::1.0.0::self-hosted. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.
#### How the latency targets were chosen
**Workflow and execution reads: 8 ms monthly p99.** `DescribeActivity`, `DescribeExecution`, `DescribeMapRun`, `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `GetExecutionHistory`, `ListActivities`, `ListExecutions`, `ListMapRuns`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.
**Definition, version, alias and tag mutation: 15 ms monthly p99.** `CreateActivity`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteActivity`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.
**Execution and task coordination: 12 ms monthly p99.** `RedriveExecution`, `SendTaskFailure`, `SendTaskHeartbeat`, `SendTaskSuccess`, `StartExecution`, `StopExecution`, `TestState`, `UpdateMapRun`. Durable transition admission and bounded workflow evaluation.
**Activity poll processing: 5 ms monthly p99.** `GetActivityTask`. Authorization, bounded task lookup and response conversion around the documented long poll.
**Bounded synchronous workflow processing: 25 ms monthly p99.** `StartSyncExecution`. Durable admission, bounded transition evaluation and final response conversion.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
#### What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.
For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.
#### Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy.
With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.
#### Scaling and target-service capacity
Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.
Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.
#### Data and behavior guarantees
Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
#### Example and diagnosis
StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.
Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
### Step Functions State Machine to Azure Durable Functions
| SLA | Service level | What is covered | Conditions |
| ------------------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workflow and execution reads | 8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation | 15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Correct request handling | 99.9% per calendar month | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.
**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
#### What this adapter does
Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or azure::1.0.0::durable-functions. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.
#### How the latency targets were chosen
**Workflow and execution reads: 8 ms monthly p99.** `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.
**Definition, version, alias and tag mutation: 15 ms monthly p99.** `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
#### What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.
For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.
#### Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy.
With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.
#### Scaling and target-service capacity
Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.
Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.
#### Data and behavior guarantees
Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
#### Example and diagnosis
StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.
Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
### Step Functions State Machine to Cloud Workflows
| SLA | Service level | What is covered | Conditions |
| ------------------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workflow and execution reads | 8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation | 15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Correct request handling | 99.9% per calendar month | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.
**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
#### What this adapter does
Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or google::1.0.0::workflows. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.
#### How the latency targets were chosen
**Workflow and execution reads: 8 ms monthly p99.** `DescribeStateMachine`, `DescribeStateMachineAlias`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.
**Definition, version, alias and tag mutation: 15 ms monthly p99.** `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
#### What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.
For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.
#### Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy.
With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.
#### Scaling and target-service capacity
Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.
Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.
#### Data and behavior guarantees
Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
#### Example and diagnosis
StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.
Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
### Step Functions State Machine to Temporal Cloud (Managed)
| SLA | Service level | What is covered | Conditions |
| ------------------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workflow and execution reads | 8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation | 15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Correct request handling | 99.9% per calendar month | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.
**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
#### What this adapter does
Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or temporalio::1.0.0::managed. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.
#### How the latency targets were chosen
**Workflow and execution reads: 8 ms monthly p99.** `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.
**Definition, version, alias and tag mutation: 15 ms monthly p99.** `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
#### What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.
For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.
#### Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy.
With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.
#### Scaling and target-service capacity
Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.
Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.
#### Data and behavior guarantees
Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
#### Example and diagnosis
StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.
Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
### Step Functions State Machine to Temporal (Self-Hosted)
| SLA | Service level | What is covered | Conditions |
| ------------------------------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Workflow and execution reads | 8 ms monthly p99 | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource` | at most 100 returned records/history events and at most 1 MiB payload. |
| Definition, version, alias and tag mutation | 15 ms monthly p99 | `aws::1.0.0::sfn`: `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Definition at most 1 MiB and at most 100 states; one named resource. |
| Correct request handling | 99.9% per calendar month | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | The request uses an operation and request shape that this adapter profile lists as available, and stays within the limits in the service page and your signed agreement. A target-service failure does not count as an adapter failure when Tensor9 correctly returns that failure to the caller. |
| Documented adapter behavior | Preserve the supported behavior documented for this adapter | `aws::1.0.0::sfn`: `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`, `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition` | Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored. |
| Endpoint reachability | 99.9% per calendar month | Adapter endpoint reachability | The agreed production deployment has healthy target connectivity and receives a valid adapter health probe. This measures the adapter endpoint, not the target provider's service. |
| Adapter autoscaling and limits | Automatic scaling within the workload and deployment limits in your agreement | Adapter behavior across requests | Your agreement states the maximum request rate, burst size, request and response sizes, concurrency, and target calls per request. Tensor9 maintains adapter capacity inside that envelope. Target-service quotas and capacity are separate. |
**What Tensor9 covers.** These service levels cover the adapter between the origin API and target API. They do not replace the target provider's SLA.
**How latency is counted.** Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
**Which terms apply.** Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
#### What this adapter does
Control calls validate and durably record state-machine definitions, versions and aliases. Execution calls admit work, evaluate ASL transitions and coordinate activities or temporalio::1.0.0::self-hosted. Time inside invoked customer services is separately observed; interpreter work, durable transition logging, retry decisions and response conversion remain covered.
#### How the latency targets were chosen
**Workflow and execution reads: 8 ms monthly p99.** `DescribeStateMachine`, `DescribeStateMachineAlias`, `DescribeStateMachineForExecution`, `ListStateMachineAliases`, `ListStateMachineVersions`, `ListStateMachines`, `ListTagsForResource`. Bounded durable-log or definition-state response mapping.
**Definition, version, alias and tag mutation: 15 ms monthly p99.** `CreateStateMachine`, `CreateStateMachineAlias`, `DeleteStateMachine`, `DeleteStateMachineAlias`, `DeleteStateMachineVersion`, `PublishStateMachineVersion`, `TagResource`, `UntagResource`, `UpdateStateMachine`, `UpdateStateMachineAlias`, `ValidateStateMachineDefinition`. ASL validation and serialized durable metadata mutation.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
#### What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter's own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it.
For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request's adapter duration first, then the monthly p99. Do not subtract one service's p99 from another's. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.
#### Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy.
With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.
#### Scaling and target-service capacity
Executions shard by execution identity; ordered transitions within one execution remain serialized. Qualification fixes definition size, history events, payload bytes, map concurrency, activity waiters and execution mix. Lists and histories are bounded pages, and a hot execution cannot monopolize unrelated workflows.
Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service's capacity with Tensor9's help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.
#### Data and behavior guarantees
Accepted transitions and task outcomes are durable and idempotent, retries follow the definition, aliases resolve consistently, and redrive never skips required history. Unsupported ASL or target integrations fail before execution rather than being silently ignored.
#### Example and diagnosis
StartExecution durably creates one execution and returns its stable ARN. A three-state workflow then records each transition; Lambda or cloud-workflow execution time is external, while ASL evaluation and log commits remain covered. GetExecutionHistory returns one bounded page from that durable sequence.
Use `tensor9 explain` and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider's latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
## Debug this service
For requests through a service adapter, use Explain and request diagnostics to investigate the selected mapping.
Follow the [BYOC service-adapter debugging runbook](/byoc/service-adapters/debugging/overview) to capture and interpret the diagnostic evidence.
[Service Catalog](/byoc/service-adapters/catalog).