How to tell if your contact form is silently dropping leads

We were doing an accessibility pass on a site in August 2026 and checked the production environment settings along the way. They were empty. Not wrong, not stale. Empty.

That site’s forms send to a CRM, and the CRM connection needs an account ID and a form ID to work. Those live in environment variables, which are the settings you keep outside your code because they’re specific to each place the site runs. Locally they sat in a file on the developer’s machine. In production they had never been added.

So all three lead endpoints, two customer journeys and a newsletter signup, returned an error to every single submission. And because someone had thoughtfully written a fallback, each failure quietly opened an email draft instead. Which brings us to the part worth internalizing.

The fallback was well intentioned. If the send fails, open the visitor’s email client with the message pre-filled so the lead isn’t lost. Reasonable on paper.

In practice it did two things. It hid the failure, because a mail draft looks like a feature rather than an error, so nobody ever reported the form as broken. And it fired a full page navigation with no visitor gesture, sending them out of the site to whatever their device decided their mail handler was. On a phone with no mail app configured, that goes nowhere at all.

A fallback that hides a failure is worse than the failure. At least a visible error gets reported.

This part matters more than it sounds. The obvious move is to submit the live form and see what happens, and that writes a junk record into the real CRM, which somebody then has to find and delete. Worse, it might trigger an automated welcome email to a fake address.

So check the settings first. Listing the production environment variables took one command and answered the question conclusively: if the keys the form needs aren’t there, the form cannot possibly be working, and no test submission is going to tell you anything you don’t already know.

Test submissions still matter, they’re just step two. Do them with a real address you control and a message body that says TEST so whoever finds it knows to bin it.

The env var problem is the one we hit. It’s not the only one, and the others are just as quiet.

Notice that in three of the five, the visitor sees nothing unusual. That’s why you can’t wait to be told. The same goes for content your scroll animations may be hiding, which is invisible from where you sit for exactly the same reason.

Do all six. Skipping the boring ones is how this happened in the first place.

1. 01Open your live site on your phone, on mobile data rather than your wifi, so you’re a stranger to your own network.
2. 02Fill the form in properly, with a real email address you can check, and put the word TEST in the message.
3. 03Submit it and write down exactly what happened. A success message? A mail draft? A spinner that never stopped?
4. 04Go to wherever submissions are supposed to land, whether that’s an inbox, a CRM or a spreadsheet, and confirm the message is actually there.
5. 05Check the spam folder before you conclude anything. This is the single most common culprit and the easiest to miss.
6. 06Reply to your own test from the account that received it, so you know the reply path works too.

If you can’t complete step 4, you don’t have a form. You have a button.

Failures are fine. Silent failures aren’t. Four rules we now hold every form to:

• Never show success unless the send actually succeeded. Wait for the confirmation, then celebrate.
• Never navigate the visitor anywhere they didn’t choose to go. Offer a link they can tap, don’t redirect them.
• Always show a real address or phone number on failure, so a motivated visitor can still reach you.
• Log the failure somewhere you look, so the second occurrence is a signal rather than a surprise.

That last one is the difference between finding this in an audit and finding it in an alert.

Forms don’t break on the day you build them. They break the day someone rotates a key, migrates a CRM, or spins up a new hosting environment that starts empty, which is exactly what happened here.

Put a recurring reminder on your calendar for the first of the month and run the ten-minute check. It takes less time than the meeting you’re about to sit in, and one caught failure pays for a year of them.

If you want the grown-up version, send submissions to two places at once: your CRM and a plain spreadsheet or inbox you own. When the fancy one breaks, you still have the lead.

It proves the path works for you, on your device, right now. It doesn’t prove it works from every browser, every mail provider, or behind a corporate firewall that blocks the script your form depends on. If leads matter enough, test from a second device on a different network.

It also won’t help with deliverability, which is its own problem. Your form can work perfectly and your confirmation emails can still land in spam because your domain isn’t set up to send mail. That’s a different afternoon.

And if you’re on a hosted website builder, the missing-keys version of this specifically doesn’t apply, because the builder owns that plumbing. The other four failure modes absolutely still do, especially notifications routed to an inbox nobody opens.