One webhook, zero leaked leads

The worst bug in go-to-market systems is the one where somebody fills in your form, sees a thank-you page, and never appears in your CRM.

It is the worst because it is silent on both ends. The prospect believes they contacted you. Your team believes nobody contacted them. Nothing errors, no dashboard turns red, and the only evidence is a slightly disappointing month that gets attributed to seasonality.

I have seen a team lose an estimated eleven percent of inbound this way for five months. The cause was a webhook that returned 200 while its downstream write silently failed on records containing an apostrophe in the company name.

Why webhooks drop and why you do not notice

A webhook is a promise from one system to call another, and promises between distributed systems get broken routinely for boring reasons. The receiving endpoint was briefly down during a deploy. A payload arrived in a shape the parser did not expect. A rate limit was hit. A field was too long. The receiver returned success before doing the work, which is extremely common and looks fine right up until the work fails.

None of these produce an alert by default, because the sending system considers its job done once it gets a 200, and the receiving system has no idea what it did not receive. That is the structural problem: absence is not an event. You cannot log a thing that never arrived.

Which means the only way to catch drops is to compare two counts that should match, and almost nobody does, because it requires the two systems to be counted by something outside both of them.

The instrumentation, which is one hour of work

Give every inbound event an identifier at the point of origin, before it leaves the source system. A form submission gets a UUID generated client-side or by the form handler, not by the CRM. Everything downstream carries that id.

Write the id twice: once into a lightweight append-only log at the moment of capture, and once into the CRM record when it lands. The capture log can be almost anything, a table with three columns, because its only job is to be the independent count.

Then run a query on a schedule that finds ids present in the capture log and absent in the CRM, older than fifteen minutes. That query is your leak detector, and it is the entire system. Anything it returns is a real prospect who contacted you and does not exist in your pipeline.

Fifteen minutes rather than immediately, because normal processing has jitter and you do not want an alert every time something takes nine seconds. Older than a day is too late for inbound, where response time is measured in minutes.

The alert should go to a human, not to a channel. A leaked lead needs somebody to manually create the record and call the person, and "somebody" needs to be a name.

Retries are not the fix, but you still want them

The instinct on hearing all this is to add retries, and retries are worth having, with two caveats.

Retry with backoff and a cap, and make the payload idempotent using the same id from above, or your retries will produce duplicate records, which is a different bad day. Idempotency is the reason the id exists at all rather than being a nice-to-have for debugging.

And understand that retries only fix transient failures. The apostrophe bug I mentioned would have retried five times and failed five times, then given up, silently, exactly as before. Retries handle the receiver being briefly down. They do nothing about the receiver being wrong, which is the more common case in practice because deploys are more reliable than parsers.

The reconciliation query catches both, which is why it is the piece to build first if you only build one.

There is a broader principle here that applies well beyond webhooks, and it is the least glamorous idea in operations: systems fail silently far more often than they fail loudly, and the failures that matter most are the ones with no error message attached. A pipeline that is missing eleven percent of its inbound looks exactly like a pipeline in a slow quarter, and every incentive in a sales organization pushes toward explaining the shortfall with a story rather than with a query.

One practical note on where to put the capture log, because this is where the idea usually dies in a planning meeting. It does not belong in your CRM. The whole point is an independent count, and a log living inside the system you are trying to verify cannot verify it: whatever bug drops the record can drop the log line too. A separate table, a separate database, or a hosted log service all work. What does not work is a field on the object whose absence you are trying to detect.

The other question that comes up is whether to reconcile in the other direction, looking for CRM records with no matching capture id. Worth doing occasionally. It catches a different and rarer failure, which is records being created by something you did not know was writing to your CRM, and every team that runs this check finds at least one forgotten integration still quietly pushing data from a tool nobody uses.

Count the thing at the source. Count it at the destination. Alert on the difference. Everything else in this article is detail.

— DealArena Team