Skip to main content
Some APIs are inherently unreliable — rate limits, eventual consistency, cold-start latency, or third-party dependencies can cause a step to fail on the first attempt even when the system under test is healthy. Reqflo’s retry behavior lets you configure a step to try again before marking it as failed, so transient issues don’t produce misleading results.

​
When to use it

  • A step calls an eventually-consistent endpoint where data may not be immediately available.
  • An external dependency (payment processor, email service, webhook delivery) has occasional latency spikes.
  • You’re running in a CI environment where timing varies and a step occasionally times out on the first attempt.
  • You’ve identified a known-flaky step and want to mark it clearly rather than leaving it as a silent false negative.
Retries are a tool for coping with genuine infrastructure flakiness — not for masking bugs in the system under test. If a step consistently fails on the first attempt, investigate the root cause before reaching for retries.

​
Key concepts

Retry count. The number of additional attempts to make after an initial failure. A retry count of 2 means up to 3 total attempts (1 initial + 2 retries). Retry delay. The wait time between attempts. A short delay is usually sufficient for transient network issues; a longer delay may be appropriate for eventual consistency scenarios where the system needs time to propagate state. Retry condition. Retries are triggered when a step fails — either because an assertion failed or because the request produced an error (for example, a timeout or a 5xx response). A step that succeeds on the first attempt never retries. Per-step configuration. Retry behavior is configured per step, not at the journey level. That lets you apply retries only where you know flakiness exists, keeping the rest of the journey’s results clean. Flaky step labeling. Marking a step as known-flaky documents the expectation in the journey itself. This is useful for communicating to your team that the unreliability is a known infrastructure issue, not a sign of a broken test.

​
How it works

When a step fails:
  1. Reqflo checks whether retry is configured for the step.
  2. If retries remain, it waits the configured delay and re-executes the step from scratch — constructing the request, sending it, and evaluating assertions again.
  3. If the step succeeds on a retry, the run continues and the step is marked as passed (with a note that it succeeded on retry).
  4. If all retry attempts are exhausted and the step still fails, the step is marked as failed and the run outcome reflects that failure.

​
Examples

Step configuration (YAML) 
steps:
  - name: confirm-webhook-delivered
    request: webhooks.confirm_delivery
    retries:
      count: 3
      delay: 2000  # milliseconds
CLI — no extra flags needed Retry configuration lives in the journey definition. When you run the journey, retries apply automatically based on how the step is configured. 
reqflo run order-flow --env staging --case "Happy path"