Delivery Attempt Log

When a platform delivers events to customer-controlled endpoints, the single most common support interaction is "we never received event X". Answering it requires knowing whether the platform attempted delivery, what the customer's endpoint returned, and when.

A delivery attempt log makes that a question the customer can answer themselves.

Why it matters more than it appears

It is usually framed as a developer-experience feature. It is actually three things:

A support cost control. Every "did you send it?" ticket becomes a link. At ecosystem scale this is a substantial share of a developer-support team's volume.

An attribution mechanism. Without it, every delivery problem is presumed to be the platform's fault, because the platform is the only party with evidence. The log establishes where the failure occurred — frequently the customer's endpoint returning 500 during their own deployment.

A recovery path. Combined with a dead-letter store and replay, a customer recovering from a four-hour outage can see exactly what they missed and re-request it. Without it, their outage is permanent data loss that they discover much later.

Implementation patterns

• Record every attempt, not only the final outcome: timestamp, response status, response time, error, and which retry number it was.
• Retain the payload for a defined window, so a customer can inspect what was sent and replay it.
• Expose it via API and console, filterable by event type, destination and status.
• Pair it with a dead-letter store holding undeliverable events, listable and replayable by the customer.
• Include a stable event id in both the payload and the log, since at-least-once delivery means the customer's deduplication key is the thing that makes duplicates harmless.
• Per-destination metrics — success rate, latency, current circuit state — visible to the customer, so they can see their own endpoint degrading before it fails.

Industry example

Communications and payments platforms, where webhooks trigger real business processes on the customer side, treat this as core product rather than as tooling. The reasoning is that the honest delivery guarantee is at-least-once, unordered, deduplicate on this id — and a guarantee that weak is only usable if the customer can see what happened.

The design around it follows the same logic: a durable queue per destination so one dead endpoint does not consume the delivery fleet; exponential backoff with jitter over hours rather than minutes, because customer endpoints go down for deployments; per-destination circuit breaking; signed, timestamped payloads so recipients can verify authenticity and reject replays; and rate-limited ramp-up when a destination recovers, so the queued backlog does not immediately knock it over again.

Every one of those mechanisms is invisible to the customer without the attempt log, which is why the log is what makes the rest legible.

Failure scenarios

• Logging only failures, so a customer cannot prove a successful delivery they did not process.
• Retention shorter than a customer's realistic outage, making replay useless exactly when needed.
• Payloads containing sensitive data retained without controls, turning a support feature into a compliance exposure.
• No replay, so the log tells customers what they lost without letting them recover it.
• Unbounded logging cost, which at high event volume is a significant storage line item and needs its own retention tiering.

Trade-offs

Storing every attempt with its payload is expensive at scale, and the data is sensitive. The usual resolution is tiered retention — full payloads for a short window, metadata for longer — plus redaction policies and access controls tied to the customer's own permissions.

The cost is real and is almost always smaller than the support burden and the trust cost of being unable to answer basic questions about your own delivery.

Interview question

"A customer says they are missing webhook events from last Tuesday. Walk me through how you would answer that — and then tell me what you would build so that they never have to ask you."