The worst contact form failure is not the one that throws an error. It is the one where the form still says "thanks, we'll be in touch", the page still turns green, and the emails stopped arriving three weeks ago.
Nobody reports it, because from the visitor's side nothing went wrong. You find out when a client asks why business went quiet, and by then you have lost a month of enquiries with no record of who tried to reach them.
Here is how forms fail silently, in rough order of how often we see it.
The recipient address was never right
Somebody typed [email protected] into a settings field eighteen months ago. The mail server accepted the message, the domain exists, and the bounce went to an address nobody monitors. Every notification since has been delivered successfully to a mailbox that does not exist.
This is the most common cause and the most embarrassing to discover.
The fix: confirm recipient addresses before they receive anything. A service that emails a confirmation link to each new recipient, and refuses to send real submissions until someone clicks it, makes this failure impossible rather than merely unlikely.
The notifications are going to spam
Your form service sends from its own domain on your behalf. Your client's mail provider decides that mail from an unfamiliar sender, containing a link and a form-shaped body, looks like phishing. Into Junk it goes, and Junk gets emptied every thirty days.
Nothing bounced. Delivery succeeded. The mail is simply not being read.
The fix: know that you cannot fully fix this, and plan accordingly. Have the client whitelist the sender, and more importantly, keep a copy of every submission somewhere that is not an inbox. If the only record of an enquiry is an email, spam filtering is a data loss event.
The mail provider had a bad afternoon
Transient failures are normal. Your provider rate limits, or returns a 421, or times out. A form backend that fires one email and moves on has just lost that message. One that queues the job, records the failure, and retries with backoff has not.
The difference is invisible on a good day and total on a bad one.
The fix: use a service that keeps delivery state and retries. Then check whether it lets you see those retries, because a retry log you cannot read is a promise you cannot verify.
A spam filter got aggressive
Some services silently drop what they score as spam. A legitimate enquiry from someone writing in ALL CAPS with three links in it gets binned, and no record is kept anywhere.
You will never know this happened. That is what makes it worse than an outage.
The fix: insist on spam being held rather than deleted. A reviewable spam folder turns a permanent loss into a five-second false positive.
Somebody changed the form
A designer edits the markup, renames the email field to Email, and now your validation rules never match, or your notification template interpolates an empty string. Or the deploy dropped the action attribute. Or a CSP change is blocking the fetch call.
The fix: a service that reports validation errors per field, and a form that has actually been tested since the last deploy.
The uncomfortable question
For every failure above, ask yourself: if this happened to a client site today, how long would it take me to find out?
For most setups the honest answer is "when the client complains". That is not a monitoring strategy, it is a hope.
What good looks like
You do not need much. Three things cover almost all of it.
Store the submission before you confirm it. If your backend writes the enquiry to a database and only then returns success, every failure downstream becomes recoverable. The email can bounce, get filtered, or never send, and the message is still there to read.
Keep a per-attempt delivery log. Not "sent: yes/no" but every attempt, with status, retry count and the error text the mail server returned. This is what turns "the form is broken" into "your IT filter rejected the last four notifications, here they are".
Watch for silence. A form that averaged twelve submissions a week and has had none for ten days is either seasonal or broken. A service that flags quiet forms catches the failures that leave no error behind, which are exactly the ones described above.
FormJetty does all three, on the free plan. Submissions are written durably before the endpoint returns 202. Every email and webhook attempt is recorded and replayable. The workspace health view flags forms that have gone quiet, alongside failed deliveries and spam spikes, and can email you a summary every day or week.
None of that makes forms stop failing. It means you find out on your terms instead of your client's.
Point one form at it and see what the log says.