Skip to main content
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:
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.
The 3-second limit applies to the upstream connection and response time. GetRequest’s own processing overhead is well under 5ms.

​
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:
1

Confirm recovery

Send a test request to your endpoint and verify you receive a 2xx response before attempting any replays.
2

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

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

Verify the response

Confirm the replay returns a 2xx. The new response appears immediately in the log detail view alongside the original failure.
For a detailed walkthrough of replaying individual and bulk requests, see Recover from production 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.
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.