Your site is up.
Your form is not.
A page that loads is not a form that works. Uptime checks confirm the server answered a request for the page; they say nothing about whether a visitor could actually submit anything. Those are separate questions, and the second one is the one that costs you enquiries.
Work down the four checks below in order. They follow the sequence the browser itself runs — click, validate, send, confirm — so the first one that fails is your answer. Most silent form failures stop at the first or the third.
Last updated 22 sep 2026 · Technical guidance, not a compatibility guarantee.
7 days free, then from $29/month. A payment method is required and $0 is charged today. Cancel before the trial ends and pay nothing.
Find the step that stops, then fix that one.
Each check has a visible result, so you never have to guess which layer is at fault. Run them in this order — a later check can look broken purely because an earlier one failed.
Does the button respond at all?
Open the page in a private window and click submit. If nothing happens — no spinner, no error, no change — the handler that should run on click never ran. That is usually a JavaScript error earlier on the page stopping every later script, a script blocked by a consent banner, or an ad blocker removing the form's own script. Open the browser console and look for the first red error, not the last.
Does validation run, and can it be satisfied?
Fill the form correctly and submit. If it refuses and highlights a field, validation is working but something is unsatisfiable — a hidden required field, a phone or postcode pattern that rejects real local formats, or a spam check that fails silently for genuine visitors. Try it on a phone on mobile data, not office WiFi: a reCAPTCHA or firewall rule that trusts your office network will reject visitors it has never seen.
Does a request actually leave the browser?
Open the Network tab in developer tools, then submit. A working form sends a request and gets a 2xx or 3xx response back. A 4xx means the server rejected it — often a security plugin, a firewall rule, or an expired token. A 5xx means the handler itself failed. Nothing at all in the list means the submission never left the page, which points back to step one.
Does the visitor get told it worked?
A request that succeeds but leaves the visitor staring at an unchanged form is still a failure. They will assume it did not send, and most will leave rather than try twice. Check that the success message, redirect or thank-you state actually appears — and that it appears on a phone, where a message rendered below the fold is invisible.
A broken form produces silence, and silence looks like a quiet week.
Every other kind of outage announces itself. A form that stops working produces exactly the same signal as nobody being interested: nothing arrives. That is why these breaks are usually found by a customer complaining weeks later, or not found at all.
Your own test passes
You test from a logged-in browser on a network the site trusts, with the same device every time. Several of the causes above only affect visitors who are none of those things, so the form works perfectly for the one person most likely to check it.
Analytics agrees with the break
If the confirmation page never loads, the conversion event never fires. The dashboard does not show an error — it shows fewer conversions, which reads as a slow month rather than a fault.
It usually follows a change
A plugin update, a new consent banner, a theme change or a tightened firewall rule are all routine, all unrelated to the form, and all capable of breaking it. The change that caused it will rarely mention forms in its release notes.
Nobody reports it
A visitor who cannot submit a form does not email you about it, because emailing you is the thing that just failed. They go to whoever is next in the search results.
What these checks will not tell you.
Each of these is a real limit rather than a caveat. Knowing which question you are actually asking saves you from fixing the wrong layer.
Whether the email arrived
Everything above happens in the browser. A submission can pass all four steps and still never reach an inbox, because the failure happens after the browser is done. If your symptom is a form that reports success but produces no email, that is a different problem with a different diagnosis.
Inside an embedded widget
If the form is rendered by another company inside an iframe — a booking tool, a payment page — the browser deliberately prevents the surrounding page from seeing inside it. What can be observed is that the embed loaded, that it was clicked, and what happened on your own page afterwards.
A form nobody tried
Nothing in this list detects a break before a real person hits it. A scheduled test that submits the form on a timer will notice sooner, which is a genuine advantage of that approach and a reason the two are often used together.
Why the visitor gave up
A long form, a demand for a phone number, or a trust problem will lose enquiries while every technical step passes. A drop in leads is not evidence of a broken form, and treating it as one sends you looking for a defect that is not there.
It watches the step you chose, during real visits.
You pick one action that matters — a contact form, a quote request, a booking step — and complete it once yourself so SiteAirbag learns what a healthy run looks like. After that it judges real visits against that run.
It does not submit anything itself
There are no scheduled test submissions, so no fake enquiries land in your inbox or your CRM. The trade-off is that it needs a real visitor to attempt the action before it has anything to judge.
It waits for combined evidence
One slow click is not a failure. A verdict needs several signals to agree, and any sign of genuine progress lowers confidence rather than raising it, because showing a backup on a working form would be worse than showing nothing.
It can offer the visitor another route
When the evidence qualifies, the visitor can be offered a backup you configured — a short message form, a callback request, a phone number, or a safe retry — so the enquiry is not lost while you fix the cause. What is offered is your choice, and it can be withheld when a retry might duplicate an order.
It is built to stay out of the way
The runtime passes your page's own network traffic through unchanged and never replays the original action. That is how it is designed rather than a guarantee that software cannot have defects. How that is built.
Find out the next time, without a customer telling you.
SiteAirbag watches a form you choose during real visits and can offer the visitor a backup way to reach you when the evidence shows the submission failed.