Skip to main content
Request replay requires a paid plan — see the FAQ for which ones.
When something goes wrong in production, the hardest part isn’t fixing the code — it’s re-running all the requests that hit during the failure window. getrequest makes this a one-click operation.

​
How replay works

Replay re-fires the exact original request to your endpoint’s destination — the same trip it originally tried to make, just later:
  • Same HTTP method
  • Same headers (including Content-Type, Authorization, and any custom headers)
  • Same query parameters
  • Same request body
getrequest sends it fresh and shows you the new response immediately. It works on Sync API and Async API endpoints — anywhere there’s a destination to send it to.

​
Replay a single request

1

Open Logs

Navigate to your project and click Logs.
2

Find the failed request

Use the Status filter to narrow to 5xx or 504. Use the time range picker to focus on the failure window.
3

Open the log entry

Click the row to open the full request/response detail.
4

Replay

Click Replay. getrequest fires the request immediately.
5

Check the response

The new status code, headers, and body appear below the original response. A 2xx means recovery was successful.

​
Replay multiple requests after an outage

For an outage that affected only a handful of requests, one-at-a-time Replay is fine:
  1. Filter Logs to the incident window and 5xx/504 statuses.
  2. Work through each row, replaying and confirming 2xx.
  3. If you see a pattern of the same endpoint failing, check your backend logs for that specific handler before replaying the rest.
Filter by endpoint first if your outage was specific to one service. Replaying across multiple backends simultaneously increases the chance of re-triggering an issue before it’s fully fixed.
For hundreds or thousands of affected requests, don’t do this one row at a time — see Bulk retry & recovering many requests for retrying a manual selection or an entire filtered set in one action, plus the Retries page that groups recurring failures for you automatically.

​
What replay does not do

  • Does not modify the original log. The original request and response are preserved exactly as captured. The replay result appears as a separate response alongside the original.
  • Does not retry automatically. Replay is always manual and intentional — getrequest will never re-fire a request without you clicking the button. (Async API’s own automatic retries are a separate thing — see Sync vs. Async endpoints.)
  • Does not work on Static API endpoints. There’s no destination to send a Static API request to, so there’s nothing to replay.
  • Does not skip destination validation. If the destination now resolves to a private, loopback, or link-local address — even if it didn’t when the request was first captured — the replay fails immediately with 502 Destination not allowed, independent of whatever caused the original failure. See Limits, timeouts & error responses.

​
Replay limits

If you exceed 20 replays per minute, wait a moment and continue.

​
After a failed deploy

Failed deploys are the most common replay scenario. The typical recovery:
  1. Roll back or fix the deploy.
  2. Verify the fix with a fresh test request.
  3. Use the time range filter to find requests that hit during the broken window.
  4. Replay them in order.
Because getrequest captures the exact timestamp of every request, you can reconstruct the precise sequence of events during the incident — one deploy, fully undone.