Skip to main content

Set the number of retries

To rerun your workflow when an exception is raised, set the retries parameter to an integer.

Retry nested flows

When a parent flow retries a direct call to a nested flow, Prefect reuses the child’s completed result if it was persisted. Set persist_result=True on the child flow to enable result persistence. If the child failed or completed without a persisted result, the parent retry creates a new child flow run. The new run has its own retry budget, while the previous run keeps its state and history. Because the child has a new flow-run ID, task caches that include the flow-run ID do not carry over from the previous child run.

Wait between retries

To add a wait between retries, pass a value to the retry_delay_seconds parameter.

Retry parts of a workflow

You can configure retries for individual tasks in a workflow to limit the scope of a retry.

Retry with configurable delay

A task’s retry delays can also be defined as a list of integers for different delays between retries.
You can also use the exponential_backoff utility to generate a list of retry delays that correspond to an exponential backoff retry strategy.

Retry with a custom condition

Whether or not a task should be retried can be determined dynamically by passing a callable to the retry_condition_fn parameter.
If a callable passed to retry_condition_fn returns True, the task will be retried. Otherwise, the task will exit with an exception.

Add jitter to retry delays

To add a random amount of time to retry delays, pass a value to the retry_jitter_factor parameter.
Adding jitter to the retry delays avoids multiple tasks introducing load to external systems by failing and retrying at the exact same cadence.

Configure task retry behavior globally

You can set the default retries and retry delays for all tasks via Prefect’s settings. The default values can be overridden on a per-task basis via the retries and retry_delay_seconds parameters.