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 visible DOM, click events, form-state signals, and lightweight JavaScript error metadata. When you scrub to the moment the user clicked Submit, you can check whether:

• The click event registered on the right element (or got intercepted by an overlay).
• A form-submit attempt appeared in the captured timeline.
• A JavaScript error signal appeared around the same moment.
• The DOM showed a loading state, validation message, redirect, or no visible acknowledgement.

In Sessions, combine Typed in any field, Typed, not submitted, and the affected landing URL. That is the current shipped approximation for "started but did not complete"; CloseTrace does not expose arbitrary clicked_element expressions.

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 JavaScript error signal appear near the click? This can reveal a handler that threw, but CloseTrace is not a replacement for full console or error-monitoring telemetry.
3. Did the page acknowledge the attempt? Check for a loading state, validation message, DOM change, or redirect. Use your application logs to determine whether a network request fired and what response came back.
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.