Replay & collections

Single replay

Every captured request has a Send button. Click it to forward the original HTTP method, headers, and body to your replay target. The status cube shows the execution progress in real time.

Batch replay

Select multiple captures (click, Ctrl+click, or Shift+click for range) and use the Send To dialog to replay them all at once. Each capture is forwarded independently — N captures × M targets = N×M parallel executions.

Collections

Save a group of captures as a named collection for reusable regression testing. Collections preserve the capture order and mark each capture as a fixture (exempt from retention cleanup).

Run a collection by clicking Run — it creates a replay sequence from the collection’s ordered captures and fires them once against your target.

Retry until 200

Click Run until 200 to keep retrying non-200 executions on a 3-minute cadence until every capture returns success. Each cycle re-enqueues only the executions that didn’t return 200 on the previous pass, so a partially successful run converges instead of re-firing everything.

Available on First Mate plans and up. The retry loop has two hard stops: 20 attempts or a 1-hour window from the initial run, whichever comes first. After the stop, the sequence is marked Failed and no further retries fire.

When to use it

• Local dev server that takes a while to come up after a restart
• Async jobs that only succeed after a dependent process finishes (DB migration, queue flush, cache warm-up)
• Flaky integration tests that need one-more-try before failing CI

When NOT to use it

Don’t point Retry until 200 at a production dependency. Three-minute hammering for an hour against a service that’s actually down is DoS-adjacent — use one-shot Run instead and let your incident tooling handle the retry policy.

Sequential replay

For production bug reproduction, replay captures in a specific order. Save captures to a collection, drag to reorder them, then click Run. The captures are sent sequentially — one after another in the order you defined. Optionally add a delay between items (0–30 seconds) and enable stop-on-failure to halt the sequence if any capture returns a non-200 response.

Capture limits

Each plan has daily capture limits and burst protection. The daily limit controls total volume; the burst limit prevents webhook providers from being throttled during normal operation (e.g. Stripe firing 10–15 events on a single checkout).

When the burst limit is exceeded, the endpoint returns HTTP 429 and stores a rejected capture in your dashboard so you can see what was rate-limited. Webhook providers automatically back off on 429 and retry — the retry succeeds once the burst window resets. When the daily limit is reached, the first 10% of excess captures are stored as rejected (so you can see you hit the cap) before the endpoint stops responding entirely. Oversized payloads are accepted (HTTP 200) but stored with a rejection reason instead of being processed.