> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getrequest.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Replay Failed Requests to Recover from Production Failures

> Use GetRequest's replay feature to re-fire captured requests after an outage, bad deploy, or misconfigured handler — without losing any data.

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.

<Note>
  Request replay requires the **Pro plan**.
</Note>

***

## 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

<Steps>
  <Step title="Open Logs">
    Navigate to your project and click **Logs** in the sidebar.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Open the log entry">
    Click the row to open the full request and response detail.
  </Step>

  <Step title="Click Replay">
    Click the **Replay** button. GetRequest fires the request to your upstream immediately.
  </Step>

  <Step title="Check the new response">
    The new status code, headers, and body appear below the original response. A `2xx` confirms the request was processed successfully.
  </Step>
</Steps>

***

## 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.

<Tip>
  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.
</Tip>

***

## 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

| Limit                  | Value   |
| ---------------------- | ------- |
| Requests per minute    | 20      |
| Endpoint type required | Forward |
| Plan required          | Pro     |

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.