Why Your Form Submit Button Isn't Working (And How to Find Out)

A visitor fills out your contact form. Name, email, company size, the optional "how did you hear about us" field. They click Submit. Nothing happens. No spinner, no error, no redirect. They click again. Still nothing. They leave.

You don't hear about it because nothing got submitted. The form didn't fail loudly — it failed silently, which is worse. Your analytics show a session that ended on the form page and you assume the copy was off or the offer was weak.

The button itself is almost never the problem. The problem is what happens (or doesn't happen) in the half-second after the click.

What "submit does nothing" actually means

When a user reports the submit button doing nothing, one of four things is happening, and they look identical from the outside:

1. The click handler never bound. The script that attaches onSubmit loaded after the user clicked, or it failed to load at all (ad blocker, CSP rule, 404 on a CDN).
2. The handler fired and threw. Usually a TypeError on a field that doesn't exist on this variant of the page, or a reference to window.dataLayer before GTM finished initializing.
3. The handler fired and silently returned false. Validation logic decided a field was invalid but the error UI is hidden, off-screen, or behind a sticky header.
4. The handler fired, posted, and the response was a CORS error or a 500. The network tab knows. The user doesn't.

Forum threads on freeCodeCamp and Treehouse will tell you to check your HTML for unclosed tags or misplaced submit buttons. That advice covers maybe 10% of cases. The other 90% live in JavaScript state that you can't see from the source.

The console-only debugging trap

The standard advice is: open DevTools, click Submit, look at the Console tab. Laserfiche threads, Stack Overflow answers, every developer playbook says the same thing.

This works when you're the one clicking the button on your own machine. It doesn't work when the broken click happened on a Pixel 6 running Chrome 119 with an ad blocker enabled, on a user's home Wi-Fi, three hours ago. You can't reproduce it because the reproduction is the entire problem.

You need a recording of the real click, not a re-enactment of it.

What replaying the click actually shows you

Session replay captures the DOM, the click events, the network requests, and any console errors that fired during the session. When you scrub to the moment the user clicked Submit, you see whether:

• The click event registered on the right element (or got intercepted by an overlay).
• A handler fired. If you've instrumented custom events, you'll see form_submit_attempted in the timeline.
• A console error appeared in the same 200ms window. This is the one that solves most cases.
• A network request went out. If yes, what status came back. If no, the handler failed before the fetch.

Filter the session recording list by clicked_element = button[type=submit] AND form_submitted = false. That segment is the bucket of "tried and failed." Everyone else is either a successful submit or someone who never clicked.

For a related failure mode — submit clicked, request sent, no confirmation shown — see form submit fails with no error message. For the Safari-specific variant, submit working in Chrome but not Safari covers the cross-browser cases.

The four checks to run on the replay

Once you've isolated a session where the button looked dead, run these four checks in order:

1. Was the click event captured at all? If the replay shows the cursor moving onto the button and pressing, but no click event in the event log, you have an overlay (cookie banner, chat widget, sticky CTA) eating the click. Inspect the z-index map of the page at that scroll position.
2. Did a console error fire within 500ms of the click? This catches handlers that threw. The error message usually names the file and line — half the time it's a third-party script (Calendly, HubSpot, Intercom) tripping on a missing global.
3. Did a network request fire to your form endpoint? If yes, look at the response. If no, the handler exited before the fetch. Almost always a validation bail-out with no visible error message.
4. Was the same user retried within 60 seconds? Multiple clicks on the same dead button is the strongest signal you have. It's also the cleanest segment to feed back to the dev team because the intent is unambiguous.

The honest limitation

Replay shows you what happened. It doesn't always tell you why. If a third-party script failed to load because of a regional CDN outage, the replay shows the resulting error but not the underlying cause. You still need server logs and a real-user-monitoring tool to correlate.

Replay also won't help with form fills that the user abandoned before clicking Submit. For that, you want form drafts and lead recovery — capturing the partial data so the half-typed lead isn't lost.

What to do tomorrow morning

Pick the form on your site with the highest commercial value — usually a demo request, a checkout step, or a contact form on a paid landing page. In your analytics, look at the last 7 days of sessions that reached the form page and did not produce a submission event. Sort by sessions where the submit button received a click but no submission followed. That's your dead-click cohort.

Open three of those sessions in CloseTrace and run the four checks above. One of them will tell you exactly which handler is silently dying — and which campaign, browser, or ad-block extension is making it happen.