Logs, Sample Rates, and Replay: A Real Debugging Workflow

A destination starts failing at 2am. Your Activity dashboard shows the dip. What it does not show you is why: which requests failed, what your automation actually sent, or what the destination said back. Guessing from a graph wastes time you don't have. ProxyHook keeps the actual request and response data for exactly this reason, but most teams never dig past the summary numbers.

Two different logs, two different jobs

Sources and Automations each have their own Logs view, and they capture different things.

A Source's Logs view records every inbound request as it arrived: headers and body, exactly as the sender sent it. That's the raw material before any filter or transformation touches it.

An Automation's Logs view is where the interesting debugging happens. It captures every event flowing through the automation, including the payload sent to each destination and the response that destination returned. That distinction matters because filters and transformations run between the source and each destination, so two destinations on the same automation can end up with completely different outbound payloads from the same inbound event.

Say a Stripe source feeds one automation with two destinations: Postgres and a Discord alert channel. A custom transformation reshapes the event into a database row for Postgres, while a separate transformation formats a short message for Discord. If Discord starts rejecting requests, you open the Discord destination's log entries directly and read the literal payload ProxyHook sent and the response Discord sent back. No re-running the transformation in your head, no guessing at what the sent payload looked like. It's right there next to the response.

Activity tells you something's wrong, Logs tell you why

The Activity view exists at the source level, the automation level, and per destination within an automation. It gives you a time-series breakdown, successful deliveries, failures, retries, and throughput, over a date range or rolling interval.

Activity is where you notice a problem: a destination's failure count climbing over a 15-minute window. It is not where you diagnose it. Once you've spotted the window, go to that destination's Logs, narrow to the same time range, and read the response bodies from the failed requests. A spike that looks identical on a graph could be an expired API key returning 401s, a schema mismatch returning 422s, or a downstream outage returning 503s. Those are three different fixes, and the graph alone can't tell them apart.

Sample rate is a dial, not a default

Logs are sampled at a configurable rate so storage costs stay predictable on high-volume sources. That's a deliberate tradeoff: only the events that get sampled are retained, which means only those events are available to inspect or replay later. An automation running at a low sample rate during a problem window may simply not have logged the requests you need.

Treat the sample rate as something you actively manage around specific moments, not a value you set once and forget:

• Right after standing up a new source or automation, raise the sample rate toward 100% while you confirm the shape of real traffic matches what you built the filters and transformations against.
• Right after changing a filter rule or a transformation, do the same for a short validation window, then dial it back down once you've confirmed the new behavior with a handful of replays.
• On a source that's been stable for months, a low sample rate is fine. You're not debugging it every day, and full logging on high-throughput traffic is the expensive case the sample rate is designed to avoid.

Replay turns a stored event into a live test

Any logged event can be replayed to re-trigger delivery, and this is the piece that makes Logs more than a read-only archive. A replayed event runs through the automation's current filter and transformation steps, not the steps that existed when it originally arrived. That's what makes it useful for verifying a change.

Take a Payload Contents filter you just added to exclude test-mode events, something like:

payload.mode != "test"

Instead of waiting for your payment provider to send a new event, find a historical test-mode event in the Logs, hit Replay, and confirm it no longer reaches any destination. Then find a live-mode event from before the filter existed, replay it, and confirm it still reaches every destination unchanged. Two replays tell you the filter is correct, without generating a single new webhook from the source system.

The same mechanism covers backfilling after an outage. If a destination goes down for twenty minutes, the events that failed during that window are sitting in that destination's Logs with their failure responses attached. Once the destination is back, open that window and replay each one to redeliver it, rather than trying to reconstruct what was missed from the source system's own records.

Start reading the responses, not just the graph

Activity graphs are good for noticing that something changed. Logs are where you find out what changed and why, because they hold the actual outbound payload and the actual response, not a summary of them. Combine that with a sample rate you actually manage around risky changes, and Replay to test filter and transformation edits against real historical events, and debugging a pipeline stops being a guessing game against a chart.

If you're currently debugging by staring at Activity counters and hoping the pattern gives it away, open the Logs view instead. The response body is usually already telling you exactly what's wrong.