Your form says “Thanks!” but the lead never arrives.
The form POST returns 200, the visitor sees success — and the lead never reaches your CRM, sheet, or inbox. Marketing keeps spending; sales reports a quiet week that doesn't match the traffic. Here is the fast triage list, and the one check most tools never run.
A submission has two halves. Uptime tools watch one.
The POST succeeds and the page shows your success message — that part is almost always fine. The lead reaching its destination is the half that silently breaks. Because the success message is usually tied to a 200 response, your site keeps looking perfect while the CRM stays empty.
Five ways a "successful" form loses leads
A Zap / Make / n8n workflow paused or ran out of tasks
Symptom: The form still returns 200, but the automation that moves the lead never ran.
Fix: Open the automation's run history. Re-enable a paused workflow, top up tasks, and add a low-task alert so it does not silently stall again.
The destination API key rotated
Symptom: Submit succeeds, but the downstream write fails with a 401 you never see.
Fix: Re-issue and update the CRM/sheet/email API token in the integration. Treat key rotation as a deploy event worth a post-change check.
A reCAPTCHA or honeypot change drops valid submissions
Symptom: Real visitors see success, but their submissions are classified as spam and discarded.
Fix: Review the anti-spam threshold and any recent CAPTCHA change. Confirm a known-good submission is not being quarantined.
The form route was renamed but the success message stayed hardcoded
Symptom: The page shows the same green confirmation even though the POST now 404s or hits the wrong handler.
Fix: Confirm the form action points at the live endpoint and that the success state is driven by the real response, not a hardcoded message.
The CRM webhook URL changed during a migration
Symptom: Everything worked until the CRM swap; now the old destination URL silently fails.
Fix: Update the destination URL everywhere the form posts to, and verify a test lead lands in the new system before trusting it.
Paste this into your incident notes
Lead form delivery triage
[ ] Search the destination (CRM/sheet) for the canary email address.
[ ] Open the Zap/Make/n8n run history; look for failed or paused runs.
[ ] Confirm the destination API token is still valid (not rotated/expired).
[ ] Submit a manual test from incognito; watch the network panel for the POST.
[ ] Check the spam quarantine if delivery is by email.
[ ] Confirm the CRM webhook URL still matches after any recent migration.
[ ] Re-run / replay any leads held while the path was broken.Two checks — and the second is the one nobody runs
The first check proves the form accepts data. The second proves the data actually arrived downstream. Submit a canary lead on a domain you own and use nowhere else, then query the destination and assert the canary appears in a recent record. Set the destination cadence at least as long as its slowest batching window to avoid false alarms.
Want this caught before sales notices a quiet week?
Start a trial, point Nightlamp at your form and its destination, and we'll watch both halves of the path — and page you the morning a lead stops landing.
Start 14-day trial · no card