Retry

Overview

The Retry action automatically retries a failed workflow step multiple times before marking it as failed. It's essential for handling transient failures and building resilient test workflows.

🔄 Purpose

Use Retry to:

• Handle transient network failures

• Account for eventual consistency

• Overcome flaky tests

• Build resilient workflows

• Reduce false negatives

---

When to Use Retry

✅ Good Use Cases

Scenario	Reason
Network Timeouts	Temporary connectivity issues
Flaky Tests	Tests that occasionally fail randomly
API Rate Limits	Server temporarily unavailable
Resource Contention	Temporary database locks
Eventual Consistency	Data not immediately available
Load-Dependent Failures	Failures under high system load

❌ Anti-Patterns (Don't Do)

• ❌ Retry permanent errors (404, 401, 403)

• ❌ Retry without delays (hammers the server)

• ❌ Excessive retry attempts (30+ retries)

• ❌ Retry as error handling (not a substitute)

• ❌ No logging of retries (can't debug)

---

Configuration

Basic Setup

1. Open your workflow

2. Click "Add Action" → Select "Retry"

3. Configure retry settings:

   • Max Attempts: Number of times to retry (1-10)

   • Initial Delay: Wait time before first retry

   • Backoff Strategy: Linear, Exponential, or Fixed

   • Max Delay: Maximum wait between retries

4. Optional: Specify error types to retry on

5. Save and connect to workflow

Configuration Options

Retry Action Configuration
├── Max Attempts: 1-10 (typically 3-5)
├── Initial Delay: 1-300 seconds
├── Backoff Strategy: 
│   ├── Fixed: Same delay each retry
│   ├── Linear: Delay increases by constant
│   └── Exponential: Delay doubles each retry
├── Max Delay: Cap on delay duration
├── Retry On: Specific error types (optional)
└── Timeout: Maximum total retry time

---

Backoff Strategies

Linear Backoff

Delay increases by constant amount:

Attempt 1: Fails immediately
Wait: 5 seconds
Attempt 2: Fails
Wait: 10 seconds (5 + 5)
Attempt 3: Fails
Wait: 15 seconds (10 + 5)
Attempt 4: Succeeds

Total time: 5 + 10 + 15 = 30 seconds

Use when: Steady, predictable wait is needed

Exponential Backoff

Delay doubles each time:

Attempt 1: Fails immediately
Wait: 2 seconds
Attempt 2: Fails
Wait: 4 seconds (2 × 2)
Attempt 3: Fails
Wait: 8 seconds (4 × 2)
Attempt 4: Fails
Wait: 16 seconds (8 × 2)
Attempt 5: Succeeds

Total time: 2 + 4 + 8 + 16 = 30 seconds

Use when: System may need increasing time to recover

Fixed Backoff

Same delay each retry:

Attempt 1: Fails immediately
Wait: 5 seconds
Attempt 2: Fails
Wait: 5 seconds
Attempt 3: Fails
Wait: 5 seconds
Attempt 4: Succeeds

Total time: 5 + 5 + 5 = 15 seconds

Use when: Consistent, simple retry needed

---

Configuration Examples

Conservative (Safe for Production)

Max Attempts: 3
Initial Delay: 5 seconds
Backoff: Exponential
Max Delay: 30 seconds

Timeline:
Attempt 1: Fails
Wait 5s → Attempt 2: Fails
Wait 10s → Attempt 3: Fails
Wait 20s → Attempt 4: Succeeds
Total: ~35 seconds

Aggressive (Fast Feedback)

Max Attempts: 2
Initial Delay: 1 second
Backoff: Fixed
Max Delay: 5 seconds

Timeline:
Attempt 1: Fails
Wait 1s → Attempt 2: Fails
Wait 1s → Attempt 3: Succeeds
Total: ~2 seconds

Moderate (Balanced)

Max Attempts: 3
Initial Delay: 2 seconds
Backoff: Linear
Max Delay: 10 seconds

Timeline:
Attempt 1: Fails
Wait 2s → Attempt 2: Fails
Wait 4s → Attempt 3: Fails
Wait 6s → Attempt 4: Succeeds
Total: ~12 seconds

---

Practical Examples

Example 1: API Retry with Exponential Backoff

Workflow: Resilient API Call

Step 1: API - Get User Data
   Configuration:
   - Max Attempts: 5
   - Initial Delay: 2 seconds
   - Backoff: Exponential
   - Max Delay: 60 seconds

Timeline on failure:
Attempt 1: Timeout
Wait 2s → Attempt 2: Timeout
Wait 4s → Attempt 3: Timeout
Wait 8s → Attempt 4: Timeout
Wait 16s → Attempt 5: Success

Example 2: Database Query Retry

Workflow: Query with Eventual Consistency

[API: Create Record]
[Wait: 1 second]
[API: Query Record]
   Configuration:
   - Max Attempts: 3
   - Initial Delay: 1 second
   - Backoff: Linear
   - Retry On: NOT_FOUND errors only

Timeline:
Attempt 1: NOT_FOUND error
Wait 1s → Attempt 2: NOT_FOUND error
Wait 2s → Attempt 3: Found successfully

Example 3: Rate-Limited API

Workflow: Handle Rate Limiting

[API: Search]
   Configuration:
   - Max Attempts: 4
   - Initial Delay: 5 seconds
   - Backoff: Exponential
   - Retry On: 429 (Too Many Requests)
   - Max Delay: 120 seconds

Timeline:
Attempt 1: 429 Rate Limited
Wait 5s → Attempt 2: 429 Rate Limited
Wait 10s → Attempt 3: 429 Rate Limited
Wait 20s → Attempt 4: Success

---

Retry Strategies

Strategy 1: Quick Retry for Network

For transient network failures:

Configuration:
  Max Attempts: 3
  Initial Delay: 1 second
  Backoff: Exponential
  Max Delay: 10 seconds
  Retry On: [Timeout, Connection Reset]

Strategy 2: Patient Retry for Async

For operations with high variance:

Configuration:
  Max Attempts: 5
  Initial Delay: 3 seconds
  Backoff: Exponential
  Max Delay: 60 seconds
  Retry On: [All errors]

Strategy 3: Selective Retry

Only retry specific errors:

Configuration:
  Max Attempts: 3
  Initial Delay: 2 seconds
  Backoff: Linear
  Retry On: [Timeout, 503 Service Unavailable, 429 Too Many Requests]
  Do NOT Retry: [404 Not Found, 401 Unauthorized]

---

Combining Retry with Other Actions

Retry + Wait

Add guaranteed delay:

[API Call]
    ↓
[Wait: 2 seconds]
    ↓
[Retry: 3 attempts with 5s backoff]
    ↓
[Next Step]

Retry + Condition

Retry only on specific conditions:

[Operation]
    ↓
IF (error_type == "transient") THEN
    [Retry: 3 attempts]
ELSE
    [Stop workflow - permanent error]

Retry + Send Email

Alert after retries exhausted:

[API Call with Retry: 5 attempts]
    ↓
IF all_retries_failed THEN
    [Send Email: Alert team]
ELSE
    [Continue normally]

---

Best Practices

✅ Do

• Start conservative - Begin with 3 attempts, increase if needed

• Use exponential backoff - Better for most scenarios

• Set max delay - Prevent excessively long waits

• Log retry attempts - Track for debugging

• Test retry configuration - Simulate failures to verify

• Monitor retry metrics - Track how often retries succeed

• Document retry decisions - Explain why specific config chosen

❌ Don't

• Retry permanent errors - Won't help with 404, 401, etc.

• Use excessive attempts - 30 retries is overkill

• Retry without delay - Hammers server, wastes resources

• Ignore error types - Be selective about what to retry

• Forget to test - Validate configuration before production

• Set delays too high - Use reasonable timeouts

• Retry data-modifying operations - Risk duplicates/inconsistency

---

Performance Considerations

Worst Case Scenarios

Configuration: 5 attempts, Exponential, Initial 10s

Worst case timeline (all fail then succeed):
Attempt 1: Fail immediately
Wait 10s → Attempt 2: Fail
Wait 20s → Attempt 3: Fail
Wait 40s → Attempt 4: Fail
Wait 80s → Attempt 5: Succeed

Total time: 150 seconds (2.5 minutes!)

Best Case Scenarios

Configuration: 5 attempts, Exponential, Initial 1s

Best case (succeed immediately):
Attempt 1: Success immediately

Total time: 0 seconds additional

Calculation Template

Total retry time = sum of all delays + original attempt time

Example with Exponential (Initial 2s, Max 60s):
= 2 + 4 + 8 + 16 + 32 (capped at 60)
= 2 + 4 + 8 + 16 + 60
= 90 seconds maximum

---

Troubleshooting

Issue: Retry succeeds but takes too long

Solution:

1. Reduce max attempts

2. Decrease initial delay

3. Use Fixed backoff instead of Exponential

4. Lower max delay cap

5. Investigate root cause of failures

Issue: Retry doesn't help, still fails

Symptoms:

• All retry attempts fail

• Same error every time

• Permanent failure (not transient)

Causes:

• Error is permanent (404, 401)

• System is down (not just slow)

• Wrong configuration

Solutions:

1. Check error type (is it truly transient?)

2. Verify system is operational

3. Consider if retry is appropriate

4. Switch to manual intervention

Issue: Retry succeeds inconsistently

Solution:

1. Increase retry attempts

2. Use more aggressive backoff

3. Increase max delay

4. Add initial Wait before first attempt

5. Investigate actual failure cause

---

Error Types to Retry

Transient Errors (Retry These)

Error	HTTP	Example
Timeout	408	Connection timed out
Service Unavailable	503	Server temporarily down
Rate Limited	429	Too many requests
Connection Reset	N/A	Network connection lost
Temporarily Unavailable	503	Maintenance or load

Permanent Errors (Don't Retry)

Error	HTTP	Reason
Not Found	404	Resource doesn't exist
Unauthorized	401	Authentication failed
Forbidden	403	Access denied
Bad Request	400	Invalid input
Method Not Allowed	405	Wrong HTTP method

---

Real-World Scenarios

E-Commerce Cart API

Scenario: Adding item to cart under load

Configuration:
- Max Attempts: 3
- Initial Delay: 2 seconds
- Backoff: Exponential
- Retry On: [Timeout, 503, Connection errors]

Timeline on failure:
Attempt 1: 503 Service Unavailable
Wait 2s → Attempt 2: 503 Service Unavailable
Wait 4s → Attempt 3: Success (load reduced)

Database Query

Scenario: Search with eventual consistency

Configuration:
- Max Attempts: 4
- Initial Delay: 1 second
- Backoff: Linear
- Retry On: [NOT_FOUND, Timeout]

Timeline:
Attempt 1: NOT_FOUND (data not replicated yet)
Wait 1s → Attempt 2: NOT_FOUND (still replicating)
Wait 2s → Attempt 3: NOT_FOUND (almost there)
Wait 3s → Attempt 4: Success (replication complete)

---

Related Topics

• Wait Action - Combine with delays

• Error Handling - Comprehensive strategies

• Action Types Overview - All actions

• Workflow Patterns - Common patterns

• Execution Flow - How execution works

---

Summary

• Retry automatically retries failed steps

• Use for transient failures only (not permanent errors)

• Exponential backoff is best for most scenarios

• Balance speed and reliability with appropriate settings

• Monitor retry success rates to validate configuration

• Combine with Wait for predictable behavior

---

Next: Learn about Stop Action for conditional workflow termination.