You cannot detect a form to CRM break by comparing two totals at the end of the week. By then the leads are cold, and a partial failure will hide inside normal variation anyway. Detecting these breaks means verifying submissions individually, close to when they happen.

Why totals do not work

Comparing "submits this week" to "contacts this week" fails for ordinary reasons:

The two systems count different things. Submits include duplicates and bots; CRM contacts are deduplicated.
They are offset in time. A submit at 23:55 becomes a contact on the next day.
A partial failure of one form out of several is invisible in a combined number.
Both numbers move for legitimate reasons, so a gap is never obviously a bug.

Any method built on reconciling aggregates will produce either constant false alarms or silence. The alternative is to track each submission as its own object with an outcome.

What per submission verification looks like

The approach is the same regardless of tooling:

Record the submit at the moment it happens, with an identifier and a timestamp.
Open a verification window. Delivery is not instant, so allow a reasonable period before judging.
Match the submission against the CRM. Exact matching, on an identifier carried through to the CRM record, is the reliable path. Matching on email inside the window is the fallback when no identifier survives the trip.
Resolve to a terminal state when the window elapses: verified, verified late, failed, or unverified.
Alert on the failure rate, not on individual failures, with a minimum volume guard.

That fourth state matters. If the check could not run at all, for example because the CRM connection was down, you did not prove a leak. Counting that as a failure produces alarms about your own monitoring. Counting it as a success hides real problems. It needs its own bucket.

What to alert on

Failure rate over a rolling window, compared to the funnel's own baseline.
A minimum volume before the rate is allowed to fire, so three submissions in a quiet hour cannot produce a 33% failure rate.
Connection health as a separate alert. An expired CRM token stops verification, and you want to know that directly rather than inferring it from a strange failure rate.
Per funnel, not per account. A break in one client's form should not be diluted by five healthy ones.

What not to alert on

Individual failures. Some fraction of submissions will never match for benign reasons, and alerting on each one trains everybody to ignore the channel. Rate and trend are the signal.

Test the path deliberately

Verification tells you when the path breaks. A periodic end to end test tells you the path still works when volume is low enough that no rate is meaningful. Submit a real form, on a real device, and confirm the record arrives with the fields populated. Do it after every change to the form, the mapping, or the integration.

Example

Illustrative scenario. A funnel averaged around forty submissions a day with a handful never matching, which was its normal baseline. After a field rename, the unmatched share climbed past a fifth of submissions within the hour. The daily total was still inside its usual range, so no volume based alert would have fired, but the rate change was unambiguous.

How Quarkad helps

This is what Quarkad's handoff verification does. Each form submit is stored as a pending handoff with a submission key, which the snippet also writes into a custom HubSpot contact property provisioned at connect time, so matching is exact rather than guessed. A hashed email inside the window is the fallback. Submissions that expire without a match are resolved, and the CRM handoff monitor fires on failure rate over a rolling window with a minimum volume. Submissions that could not be checked are excluded from the failure count but still counted in volume, so the rate stays honest. See HubSpot CRM handoff monitoring and form monitoring.

FAQ

How long should the verification window be? Long enough to cover your slowest normal delivery, and short enough that detection is still useful. An hour suits most direct integrations; automation platforms with queues may need more.

Does this require storing personal data? It does not require storing raw email addresses. Quarkad matches on a hashed email rather than the address itself when the exact identifier is unavailable.

How to Detect Form-to-CRM Breaks