Skip to main content
When something goes wrong in production, the hardest part isn’t patching the code — it’s re-running every request that hit your backend during the failure window. GetRequest captures the exact original request for every call that came through, so recovery is a deliberate, one-click operation rather than a guessing game.
Request replay requires the Pro plan.

​
How replay works

Replay re-fires the exact original request to your Forward endpoint’s upstream. GetRequest preserves every detail of what the caller sent:
  • HTTP method — GET, POST, PUT, DELETE, or any other method
  • Headers — including Content-Type, Authorization, and all custom headers
  • Query parameters — reproduced exactly as received
  • Request body — the original payload, byte-for-byte
GetRequest sends it fresh to your upstream and shows you the new response immediately, right below the original in the log detail view.

​
Replay a single request

1

Open Logs

Navigate to your project and click Logs in the sidebar.
2

Find the failed request

Use the Status filter to narrow results 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 and response detail.
4

Click Replay

Click the Replay button. GetRequest fires the request to your upstream immediately.
5

Check the new response

The new status code, headers, and body appear below the original response. A 2xx confirms the request was processed successfully.

​
Replay multiple requests after an outage

When an outage affects many requests, work through the failed entries systematically:
  1. Filter Logs to the incident time window and set the status filter to 5xx or 504.
  2. Open each row, replay it, and confirm a 2xx response before moving to the next.
  3. If you see the same endpoint failing repeatedly, investigate that specific handler in your backend before replaying the remaining entries.
Filter by endpoint slug first if the outage was isolated to one service. Replaying traffic across multiple backends at the same time increases the risk of re-triggering a problem before it’s fully resolved.

​
What replay does not do

Understanding replay’s scope prevents surprises during recovery:
  • Does not modify the original log. The original captured request and response are preserved exactly as-is. The replay result appears as a separate entry alongside the original — it never overwrites history.
  • Does not retry automatically. Replay is always a deliberate, manual action. GetRequest will never re-fire a request without you clicking the button.
  • Does not work on JSON endpoints. Replay requires a Forward endpoint with a configured upstream URL. JSON endpoints have no upstream to send the request to.

​
Replay limits

If you exceed 20 replays per minute, wait a moment and continue working through the queue.

​
After a failed deploy

Failed deploys are the most common replay scenario. Here’s the typical recovery workflow:
  1. Roll back or push a fix to your deployment.
  2. Verify the fix by sending a fresh test request and confirming a 2xx response.
  3. Use the time range filter to isolate requests that hit during the broken window.
  4. Replay them in chronological order.
Because GetRequest captures the exact timestamp of every request, you can reconstruct the precise sequence of events during the incident and process them in the same order they originally arrived.