Debugging Webhook Failures with Source and Automation Logs

A destination starts failing at 3am. Nobody notices until someone asks why a Slack channel has gone quiet, or why the rows in Postgres stopped a few hours ago. By the time you're looking, you don't just need to know that something broke. You need to know which destination, since when, why, and how to get the events that were dropped in between without waiting for the upstream service to resend them.

ProxyHook splits that investigation across two different Logs views, and the split isn't arbitrary. Each one answers a different question.

Two logs, two questions

Source Logs answer "did the event arrive at all?" Every request that hits your Source endpoint is captured here, including the raw payload, headers, and response code ProxyHook sent back. If nothing shows up in a time window where you expected traffic, the problem is upstream of ProxyHook entirely, the third-party service either isn't sending, or its webhook subscription is misconfigured.

Automation Logs answer a different question: "what did each Destination actually receive, and what did it say back?" This view captures every event flowing through the Automation, including the exact payload sent to each Destination and the response that Destination returned. If Source Logs show the event arrived fine, but a Destination isn't getting updated, this is where the answer lives, not in the request you sent, but in the reply you got.

Conflating these two is the most common way to waste an hour on a webhook incident. Checking Source Logs when the problem is a Destination rejecting the payload just confirms, correctly and unhelpfully, that the event arrived. Checking Automation Logs when nothing reached ProxyHook in the first place just shows you an empty view with nothing to diagnose.

Triage in the right order

Start at the Automation's Activity view, not the logs. It gives you a time-series breakdown for the entire Automation or for any single Destination inside it: successful deliveries, failures, retries, and throughput, over a date range or rolling interval you pick. This is where you first see that, say, your Postgres destination's failure count started climbing at 2:47am while your Slack destination kept a clean run. That single view tells you which destination is unhealthy and roughly when it started, before you've opened a single log entry.

With a destination and a time window identified, the next step depends on what Activity showed you:

• If the Automation's total deliveries dropped to zero, go to Source Logs first. Nothing reaching the source at all points at the sending service, not at ProxyHook or the destination.
• If deliveries are happening but failing for one specific destination, skip straight to Automation Logs and look at the entries for that destination in the failure window. The response body it returned is the actual error, not a guess. A Postgres destination that started rejecting rows because a column was renamed will show that in the response it sent back. An Airtable destination with an expired token will show an authorization error in the same place.

This ordering matters because it turns "something is broken" into "this destination, this time window, this specific rejection reason" in two lookups instead of a blind search through everything.

Recovering the events you missed

Once you've fixed the underlying problem (re-authed the connection, restored the missing column, whatever the response body told you), the events that failed during the outage are still sitting in Automation Logs. Each logged event can be replayed, which re-triggers delivery by re-running that exact event through the Automation, including its filter and transformation steps, and re-sending it to the destination.

That last part is worth being precise about: replay isn't a raw resend of the stored payload. It goes back through the same filter and transformation steps the original event went through, so if you've adjusted a filter or transformation since the failure, you'll see the corrected behavior on replay rather than reproducing the original bug. That also makes replay useful outside of incidents, as a way to confirm a filter or transformation change is doing what you think without waiting for a new live event to test it against.

For an outage that spans a handful of events, replaying them one at a time from Automation Logs is quick. For a longer window, the workflow is the same, just repeated: filter the log view down to the failed entries for the affected destination, and replay each one now that the fix is live.

Set your sample rate before you need it, not after

Source Logs are sampled at a configurable rate, specifically so storage costs stay predictable on high-volume sources. That configuration decision has real consequences during an incident: if a source is sampled at a low rate to save on storage, and the failure happens to land in the unsampled gap, you lose visibility into exactly the traffic you needed to inspect.

The rate you pick should track how much you'd regret losing that visibility versus how much log volume actually costs you to keep. A source firing a few dozen events a day from a form integration costs almost nothing to log at full resolution, so there's little reason to sample it down. A high-throughput source firing thousands of events an hour is a different tradeoff: full logging gets expensive fast, so a lower sample rate is reasonable, but it's worth setting deliberately rather than leaving at a default and discovering the gap mid-incident.

Build the habit before the outage

None of this requires anything special during setup. Logs and Activity are on by default for every Source and Automation. The only decision that benefits from being made in advance is the sample rate on your highest-volume sources, and that's a one-time setting, not an ongoing chore. Everything else, the Activity breakdown, the Source and Automation Logs split, and replay, is there the moment you need it. Knowing which view answers which question is what turns a 3am page into a two-lookup fix instead of an open-ended search.