# Defining Automatic Block-Retry Policies

- Published on May 6, 2026

In order for a submission’s processing to be completed, each block in its flow must finish its task successfully. If a block fails, the submission becomes halted, which may cause the submission to breach its SLA. When you define automatic retry policies for blocks, you minimize the chances of submissions being halted due to temporary outages, which prevents processing delays from occurring. For each retry policy, you can specify the number of times blocks should be retried, along with the amount of time that should pass between retry attempts.

## Defining block-retry policies

You can define block-retry policies at the following levels:

- **The system level**  
  This policy is the default for all blocks.
- **The flow level**  
  Each flow-level policy overrides the system-level policy for the blocks in the flow.
- **The block level**  
  Each block-level policy overrides the system-level and flow-level policy for the block.

When defining these policies, note that each retry may not occur after the exact amount of time specified for the retry interval. Retries are scheduled to occur after their retry intervals pass, but depending on the priority of the blocks’ tasks, they may not be executed at their scheduled times.

This article describes how to define block-retry policies in the application. If you’re creating custom flows, see the [Flows SDK documentation](https://flows-sdk.hyperscience.ai/pages/source-docs.html#module-flows_sdk.error_handling) to learn how to define these policies with the Flows SDK.

### Defining the default block-retry policy

To define the system-level block-retry policy:

1. Go to _/admin/hyperflow/wfeconfig/_, and click the number in the **ID** column.
2. In the **Default error handling policy** field, enter the details of your retry policy in JSON format:

```json
   {
     "block_error_retry_policy": {
       "method": "",
       "retry_count": ,
       "retry_interval_seconds":
     }
   }
   ```

The table below describes the valid _method_ values and their effects on retry-attempt intervals:

| **_method_ value** | **Effect on retry-attempt intervals** |
|-------------------|-----------------------------------|
| _FIXED_           | The number of seconds specified in _retry\_interval\_seconds_ is used as the retry-attempt interval for all retry attempts. |
| _LINEAR\_BACKOFF_| The number of seconds between retry attempts is calculated as follows:<br>_retry\_interval\_seconds_ \* the number of the attempt<br>**Example**<br>If _retry\_interval\_seconds_ = 5, the system waits 5 seconds to initiate the first retry attempt (5 \* 1). If that attempt fails, the system waits 10 seconds to initiate the second attempt (5 \* 2), and so on. |
| _EXPONENTIAL\_BACKOFF_ | The number of seconds between retry attempts is calculated as follows:<br>_retry\_interval\_seconds_ \* 2^(the number of the attempt - 1)<br>**Example**<br>If _retry\_interval\_seconds_ = 5, the system waits 5 seconds to initiate the first retry attempt (5 \* 1 = 5). If that attempt fails, the system waits 10 seconds to initiate the second attempt (5 \* 2 = 10), and so on.<br>Note that the difference between _LINEAR\_BACKOFF_ and _EXPONENTIAL\_BACKOFF_ only takes effect from the third attempt onward. |

#### Example policies
- A policy where up to 3 retry attempts will be made with 60-second intervals between each attempt:
    ```json
    {
      "block_error_retry_policy": {
        "method": "FIXED",
        "retry_count": 3,
        "retry_interval_seconds": 60
      }
    }
    ```

- A policy where up to 4 retry attempts will be made, waiting 30 seconds for the first retry, then 60 seconds for the second, following _LINEAR_BACKOFF_:
    ```json
    {
      "block_error_retry_policy": {
        "method": "LINEAR_BACKOFF",
        "retry_count": 4,
        "retry_interval_seconds": 30
      }
    }
    ```

- A policy where up to 5 retry attempts will be made, waiting 4 seconds initially, then doubling for each subsequent attempt:
    ```json
    {
      "block_error_retry_policy": {
        "method": "EXPONENTIAL_BACKOFF",
        "retry_count": 5,
        "retry_interval_seconds": 4
      }
    }
    ```

### Defining a block-retry policy at the flow level

To define a block-retry policy at the flow level:
1. Go to the Flows page, and click on the name of the flow you want to define a block-retry policy for.
2. In the flow settings, find the **Retry Failed Blocks** section, and click **Edit**.
3. Select one of the following options:
   1. **System Default**
   2. **Do not retry failed blocks in this flow**
   3. **Custom rule for this flow**
4. If you selected **Custom rule for this flow**, click **More Options** to reveal the options available to you, and:
   1. Enter the number of times blocks should be retried after they fail.
   2. Enter the number of minutes and seconds, that should pass before the initial retry attempt.
   3. To determine subsequent retry intervals, choose one of the following:
      - **Linear Function** — initial retry-attempt interval \* the number of the attempt
      - **Exponential Function** — initial retry-attempt interval \* 2^(the number of the attempt - 1)
      - **Keep wait time constant** — Same retry-attempt interval is used between all attempts.
5. Click **Confirm** and **Save** to save your changes.

### Defining a block-retry policy for an individual block

To define a block-retry policy for a specific block:
1. Go to the Flows page, and click on the name of the flow containing the block you want.
2. Click on the block in Flow Studio, find the **Retry Failed Blocks** section in its settings, and click **Edit**.
3. Select one of the following options:
   1. **Inherit from flow retry policy**
   2. **Do not retry when failed**
   3. **Custom rule for this block**
4. If you selected **Custom rule for this block**, click **More Options** to reveal the options available to you and:
   1. Provide the number of times the block should be retried after it fails.
   2. Provide the number of minutes and seconds for the initial retry attempt.
   3. Choose the subsequent retry intervals as described above.
5. Click **Confirm** and **Save** to save your changes.

### Applying retry policies to sub-flows

If you’ve connected a flow block to another flow, and that flow is not a notification flow, the block’s retry policy applies to the connected flow and its sub-flows.

If you’ve connected a flow block to a notification flow, you need to define a separate retry policy for the connected flow.

### Best practices for retry policies

When determining the length of your retry-attempt intervals, consider the following:
- Retry intervals should allow enough time for potential issues to be resolved. Short intervals may lead to unsuccessful attempts, while longer intervals can impact submission-processing times and affect SLAs.