What to log when a webhook fails only for one customer

When a webhook fails only for one customer, the log needs enough context to separate product bugs, customer endpoint problems, and delivery timing issues.

A single-customer webhook failure is hard because the system may be healthy overall. Global status pages stay green, test events pass, and most customers receive events. The failing customer still sees missing automation, stale data, or repeated retries. Without the right log fields, support can only ask for screenshots and engineering has to search across several systems.

The minimum useful log should include event id, customer account id, endpoint URL host, event type, created time, first delivery time, last retry time, HTTP status code, response timeout, retry count, payload size, signature verification status, and final delivery state. Store the response body carefully. A short safe excerpt is useful, but full bodies may contain private data or secrets from the customer endpoint.

Add a reason category, not only raw status. A 401 suggests authentication or signature mismatch. A 404 may mean a removed endpoint. A 429 means the receiver is rate limiting. A 500 can be the receiver, but repeated 500s after a deploy may still point back to a payload shape change. Timeouts need duration and region because the receiver may be slow only from one network path.

The customer-facing support view should show less than the internal log but more than "failed." It can show event type, delivery time, status code, retry schedule, and a copyable event id. That gives the customer something useful to send to their own developer.

For small SaaS teams, the best webhook log is one that lets support answer the first ticket without asking engineering to reconstruct the delivery timeline. If one customer fails repeatedly, the timeline is the product.

What to log when a webhook fails only for one customer

// COMMENTS

ON THIS PAGE