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

# Handle Backend Downtime and Outage Recovery with GetRequest

> Learn how GetRequest captures every request during an outage, surfaces the failure details, and lets you replay traffic once your backend recovers.

When your backend goes down, requests don't disappear — GetRequest captures all of them. You get a complete, timestamped record of everything that arrived while your upstream was unavailable, so recovery is a matter of replaying what you already have rather than wondering what you missed.

## What happens during an outage

With a **Forward** endpoint, GetRequest proxies every incoming request to your upstream URL. When your backend is unreachable or returns an error, GetRequest still does its job:

1. The full incoming request is captured — method, path, headers, and body.
2. The upstream response is recorded, including `5xx` errors, timeouts, and connection failures.
3. The original caller receives the upstream error status directly.
4. A log entry is saved with complete failure details.

Nothing is silently dropped. Every request that reached GetRequest during the outage is preserved in your Logs.

***

## The 3-second timeout

Forward endpoints wait up to **3 seconds** for your upstream to respond. If your backend takes longer — or doesn't respond at all — GetRequest returns:

```http theme={null}
HTTP 504 Gateway Timeout
```

The full request is still logged with the 504 status. Once your backend is back, you can replay those log entries to recover the lost traffic.

<Note>
  The 3-second limit applies to the upstream connection and response time. GetRequest's own processing overhead is well under 5ms.
</Note>

***

## Identify what failed

Open **Logs** and filter by status code to surface everything that failed during the incident:

1. Set the **Status** filter to `5xx` or `504`.
2. Set the **Time range** to the incident window.
3. Click any row to inspect the full request — what the caller sent, what your backend returned (or failed to return), and how long it took.

This gives you an exact record of blast radius: how many requests failed, which endpoints were affected, and the precise time window.

***

## Recovery steps

Once your backend is healthy again, follow these steps to restore the lost traffic:

<Steps>
  <Step title="Confirm recovery">
    Send a test request to your endpoint and verify you receive a `2xx` response before attempting any replays.
  </Step>

  <Step title="Find the failed requests">
    In **Logs**, filter by `5xx` and `504` status codes and set the time range to your incident window. Every failed request is listed there.
  </Step>

  <Step title="Replay each request">
    Open a failed log entry and click **Replay** (Pro). GetRequest re-fires the exact original request — same method, headers, query parameters, and body — to your upstream.
  </Step>

  <Step title="Verify the response">
    Confirm the replay returns a `2xx`. The new response appears immediately in the log detail view alongside the original failure.
  </Step>
</Steps>

For a detailed walkthrough of replaying individual and bulk requests, see [Recover from production failures](/guides/recover-failures).

***

## Switch to JSON mode during planned maintenance

If you're taking your backend down intentionally — for a deploy, a migration, or scheduled maintenance — switch affected endpoints to **JSON** mode before you start. This eliminates 504s entirely and keeps callers informed:

1. Edit the endpoint and change **Action** to `JSON`.
2. Set a meaningful response body, such as a maintenance message or a cached last-known-good payload.
3. Callers receive your JSON response immediately instead of a 504.
4. All requests during the maintenance window are still logged.
5. When your backend is back, switch the endpoint back to `Forward` and replay anything that came in during the window.

<Tip>
  Pair JSON mode with replay to make planned maintenance completely transparent to callers. They get a clean response during the window, and your backend processes the real requests as soon as it's ready.
</Tip>