Skip to main content

Overview

Temporal automatically retries failed activities and child workflows according to configurable retry policies:
  • Exponential backoff - Increasing delays between retry attempts
  • Maximum attempts - Limit total retry count
  • Timeout controls - Cap retry duration
  • Non-retriable errors - Fail immediately for specific error types
  • Backoff coefficient - Control retry delay growth rate
Retry policies are core to Temporal’s reliability guarantees. Configure them carefully to balance fault tolerance with resource usage.

Retry Policy Configuration

duration
required
Delay before the first retry attemptDefault: 1 second
float
required
Multiplier for retry delay on each attemptDefault: 2.0
duration
Maximum delay between retriesDefault: 100x initial interval
int
Maximum number of retry attempts (0 = unlimited)Default: 0 (unlimited)
[]string
Error types that should not be retried

Exponential Backoff Formula

Retry delay calculation:

Example: Default Policy

With default settings (initialInterval=1s, backoffCoefficient=2.0, maximumInterval=100s):

Activity Retry Policies

Configure retries when scheduling activities:

Workflow Retry Policies

Configure retries for workflows and child workflows:
Workflow retries create a new workflow execution run. The workflow will restart from the beginning on each retry.

Server-Side Configuration

Default retry policies can be configured in dynamic config:

Non-Retriable Errors

Specify error types that should fail immediately without retry:

Error Matching

Error type matching rules:
  1. Exact type name match - "ValidationError" matches ValidationError type
  2. Package path match - "myapp/errors.ValidationError" matches fully qualified type
  3. Wildcard match - "*ValidationError" matches any package
Non-retriable error checking is implemented in service/history/workflow/activity.go:

Retry Timeouts

Retries interact with activity and workflow timeouts:

Activity Timeouts

ScheduleToStart

Time from schedule to worker pickup. Retries reset this timeout.

StartToClose

Time for single attempt. Each retry gets full StartToClose timeout.

ScheduleToClose

Total time including all retries. Stops retry loop when exceeded.

Heartbeat

Heartbeat timeout. Retries reset on heartbeat timeout.

Retry Until ScheduleToClose

Activity will retry until:
  • ScheduleToCloseTimeout (10 minutes) is exceeded
  • OR activity succeeds
  • OR non-retriable error occurs

Best Practices

Match backoff to downstream service recovery time:
  • Fast recovery (seconds): initialInterval=1s, backoffCoefficient=1.5
  • Slow recovery (minutes): initialInterval=30s, backoffCoefficient=2.0
  • Rate limited APIs: initialInterval=5s, maximumInterval=5m
Set maximumAttempts for costly activities:
Don’t waste resources retrying permanent failures:
Prevent infinite retry loops:

Monitoring Retry Behavior

Key metrics for retry monitoring:
  • activity_task_schedule_to_start_latency - Time waiting for worker (increases with retries)
  • activity_execution_failed - Failed activity attempts (includes retries)
  • activity_execution_failed_total - Activities failed after all retries
  • activity_retry_count - Number of retry attempts per activity

Implementation Details

Retry logic is implemented in:
  • Activity retries: service/history/workflow/activity.go
  • Workflow retries: service/history/workflow/mutable_state_impl.go
  • Backoff calculation: common/backoff/retry.go
  • Timer scheduling: History Service timer queue
Retry state is persisted in workflow mutable state:

See Also

Activities

Learn about activity execution and timeouts

Workflows

Understand workflow execution model

History Service

Deep dive into retry implementation