Timeouts and Retry Policies
In Temporal, timeouts detect application failures. The system can then automatically mitigate these failures through retries. Both major application function primitives, Workflows and Activities, have dedicated timeout configurations and can be configured with a Retry Policy.
Follow one of our tutorials to Get started exploring timeouts and Retry Policies.
Workflow timeouts
Each Workflow timeout limits a different aspect of a Workflow Execution, and you set them when you start the Workflow Execution.
- Workflow Execution Timeout: the maximum time a Workflow Execution can stay Open, including retries and any use of Continue-As-New. The default is infinite.
- Workflow Run Timeout: the maximum duration of a single Workflow Run, which excludes retries and Continue-As-New. The default matches the Workflow Execution Timeout.
- Workflow Task Timeout: the maximum time a Worker has to execute a Workflow Task after picking it up from the Task Queue. The default is 10 seconds, with a maximum of 120 seconds.
Workflows are built to run for long periods and to survive failures, so most applications don't need a Workflow Execution Timeout or Workflow Run Timeout. A timeout limits how long a Workflow can absorb delays. To act after a set period inside a Workflow, use a Timer instead. Workflow Execution and Workflow Run Timeouts are most often used to bound a Temporal Cron Job.
Set Workflow timeouts and Retry Policies in your language:
.NET SDK
Set Workflow timeouts and Retry Policies in C# and .NET.
Go SDK
Set Workflow timeouts and Retry Policies in Go.
Java SDK
Set Workflow timeouts and Retry Policies in Java and other JVM languages.
PHP SDK
Set Workflow timeouts and Retry Policies in PHP.
Python SDK
Set Workflow timeouts and Retry Policies in Python.
Ruby SDK
Set Workflow timeouts and Retry Policies in Ruby.
Rust SDK
Set Workflow timeouts and Retry Policies in Rust.
TypeScript SDK
Set Workflow timeouts and Retry Policies in TypeScript and JavaScript.
Activity timeouts
Activity timeouts tell a Workflow which kind of Activity failure occurred, and the Activity's Retry Policy decides what happens next.
- Schedule-To-Start Timeout: the maximum time an Activity Task can sit in the Task Queue before a Worker picks it up. The default is infinite, and this timeout never triggers a retry, because a retry would return the Activity Task to the same Task Queue.
- Start-To-Close Timeout: the maximum time for a single Activity Task Execution. The default matches the Schedule-To-Close Timeout.
- Schedule-To-Close Timeout: the maximum time for the whole Activity Execution, from the first Activity Task being scheduled to the last one closing. The default is infinite.
- Heartbeat Timeout: the maximum time between Activity Heartbeats, the pings a Worker sends to report that an Activity Execution is still making progress.
Every Activity Execution needs either a Start-To-Close or a Schedule-To-Close Timeout. Set Start-To-Close: the Temporal Service can't tell when a Worker crashes or loses contact, so it relies on this timeout to retry the Activity. Long-running Activities should also Heartbeat and set a Heartbeat Timeout, which detects a lost Worker sooner than a long Start-To-Close Timeout can.
Set Activity timeouts and Retry Policies in your language:
.NET SDK
Set Activity timeouts and Retry Policies in C# and .NET.
Go SDK
Set Activity timeouts and Retry Policies in Go.
Java SDK
Set Activity timeouts and Retry Policies in Java and other JVM languages.
PHP SDK
Set Activity timeouts and Retry Policies in PHP.
Python SDK
Set Activity timeouts and Retry Policies in Python.
Ruby SDK
Set Activity timeouts and Retry Policies in Ruby.
Rust SDK
Set Activity timeouts and Retry Policies in Rust.
TypeScript SDK
Set Activity timeouts and Retry Policies in TypeScript and JavaScript.
Resources
For a deep dive into timeouts and Retry Policies visit the following Temporal Encyclopedia pages or enroll in one of our courses.
Detecting Workflow failures
Workflow Execution, Workflow Run, and Workflow Task Timeouts in detail, plus how to find Workflows with failed Workflow Tasks.
Detecting Activity failures
Schedule-To-Start, Start-To-Close, Schedule-To-Close, and Heartbeat Timeouts in detail, plus which Activities should Heartbeat.
Retry Policies
How attempts, intervals, backoff coefficients, and non-retryable errors shape a retry.