Skip to main content
Transient failures are a fact of life in distributed systems: a webhook endpoint returns a 503, an external database briefly rejects connections, or an API rate-limit window resets in a few seconds. Retry policies let you tell fsckmsft exactly how to respond when a step fails — how many times to try again, how long to wait between attempts, and how long to keep extending that delay before giving up.

​
The default retry policy

Every workflow step comes with a sensible default retry policy out of the box. Unless you override it, fsckmsft applies:
SettingDefault value
Max retry attempts3
Backoff strategyExponential
Initial delay1 second
Max delay60 seconds
With exponential backoff and a 1-second initial delay, the retry timing looks like this: attempt 1 at 1 s, attempt 2 at 2 s, attempt 3 at 4 s. If all four attempts (the original plus three retries) fail, the step is marked as permanently failed and your configured On Failure behavior takes over.

​
Backoff strategies explained

​
Configure a per-step retry policy

1
Open the step configuration
2
Click the step node you want to configure on the workflow canvas. The configuration panel slides open on the right.
4
Scroll to the Retry section (or click the Retry tab if it appears as a separate panel section). You’ll see the current policy with each field editable.
5
Set Max Retry Attempts
6
Enter a number between 0 (no retries — fail immediately) and 10. Higher values extend the total possible run time significantly, especially with exponential backoff.
7
Choose a Backoff Strategy
8
Select Exponential, Linear, or Fixed from the dropdown.
9
Set Initial Delay and Max Delay
10
  • Initial Delay: the wait time before the first retry, in seconds (minimum: 1 s, maximum: 300 s).
  • Max Delay: the ceiling on the computed wait — useful for exponential backoff to prevent very long waits on later attempts (minimum: 1 s, maximum: 3,600 s / 1 hour).
    • 11
    Save and test
    12
    Click Save. Use the run simulator with a sample payload that causes the step to fail (for example, point a webhook action at a temporarily unreachable URL) to verify the retry timing in the execution trace.

    ​
    Example configuration panel

    After saving, the Retry section summarizes your policy in plain language: 
    Retry Policy: Exponential backoff
Max attempts: 5
Initial delay: 2 s  |  Max delay: 120 s

Attempt schedule (approximate):
  Attempt 1 (original): immediate
  Attempt 2 (retry 1):  2 s
  Attempt 3 (retry 2):  4 s
  Attempt 4 (retry 3):  8 s
  Attempt 5 (retry 4):  16 s
  Attempt 6 (retry 5):  32 s
  ─────────────────────────────
  Give up after:        ~62 s total

    ​
    Disabling retries for non-idempotent steps

    Never enable retries on steps that are not idempotent — that is, steps where repeating the same call more than once causes unintended side effects. Classic examples include: sending an email or SMS (retrying sends duplicates), charging a payment method (retrying double-charges the customer), and creating a new record with a server-generated ID (retrying creates duplicate records). For these steps, set Max Retry Attempts to 0 and instead handle failures with an error branch or the Continue on Error setting.
    To disable retries for a step:
    1. Open the step configuration panel.
    2. Navigate to Retry.
    3. Set Max Retry Attempts to 0.
    4. Click Save.
    The step will fail immediately on error without any retry attempts, giving you full control over recovery through your On Failure configuration.

    ​
    Workflow-level retry defaults

    You can change the default retry policy applied to all new steps added to a workflow, without reconfiguring each step individually.
    1. Open the workflow editor.
    2. Click Settings (the gear icon).
    3. Under Default Retry Policy, update the fields.
    4. Click Save Settings.
    Existing steps are not affected — this only applies to new steps added after saving. To apply a new default to existing steps, open each step’s Retry section and click Reset to workflow default.

    ​
    FAQ

    Yes. Each retry attempt is counted as one additional action toward the actions-per-run quota for that run. Factor in your maximum retry count when designing steps in workflows that are close to the actions-per-run ceiling.
    Yes. In the Retry section, enable the Add jitter toggle. When jitter is on, fsckmsft randomizes the wait time by ±25% of the computed delay, which spreads out retries across multiple concurrent runs and reduces the chance that all retrying runs hammer a recovering service simultaneously.
    With the maximum settings (10 retries, exponential backoff, 2-second initial delay, 3,600-second max delay), a step can spend up to approximately 9.8 hours across all retry attempts before permanently failing. Workflow runs remain active during retry waits and count as one run against your quota for the entire duration.