The form said it was on its way and sent nothing

Not a trickle. None.

The obvious explanation is that nobody was writing, and for a while I believed it. The obvious explanation was wrong, and finding out why meant taking apart three things that had nothing to do with each other except that all three were invisible from the outside.

The form posted to my own endpoint, which handed the message to an email service and reported success the moment that service accepted it.

Everything after that hop was invisible to the site. Whether the mailbox existed. Whether it forwarded anywhere. Whether it was quietly filed as spam. The site could report success perfectly honestly and still be the reason nothing arrived, because it was reporting on the only part of the journey it could see.

I had been treating acceptance as delivery. They are not the same claim and only one of them was ever being made.

The fix is not clever. Every accepted send now writes a line I can look up afterwards, carrying the number of recipients it went to. A success response with no matching line means nothing was sent at all. That distinction simply did not exist before, so there was no way to tell a working form from a broken one without asking someone to write to me and then asking whether they had.

The intro-call dialog had its own problem, and it was a one-word one. On success it revealed the confirmation panel by adding a class that was styled nowhere in the stylesheet, while the panel's own rule kept it hidden by default.

So a successful booking hid the form and showed an empty dialog. The request went. The person saw a blank box and reasonably concluded it had failed.

Nothing static can catch this. The markup is valid, the class name is spelled correctly, and the only thing wrong is that no rule anywhere gives it meaning. It is only visible if something actually drives the form and then looks at what is on the screen afterwards, which is now what happens.

The form had a timing check to refuse submissions made faster than a person can type. It answered a too-fast submit by showing the success panel and sending nothing — quietly, on the theory that a bot does not need to be told it failed.

It also treated any submit with no recorded first interaction as too fast.

A password manager can fill in every field and press send without the page ever registering that a human touched it. So a real person, using an ordinary browser feature, could be told their message was on its way while nothing left their machine.

That is the one that kept me up. A missing interaction now counts as unknown and sends. A genuinely too-fast submit is refused visibly, on screen, and can simply be sent again — which is what someone who is not a bot will do.

None of these three were visible from outside. The form looked like it worked and said so, which is worse than a form that plainly fails.

Someone who sees an error tries again, or emails you, or picks up the phone. Someone who sees on its way does none of those things. They have already been told the job is done, so the failure costs you the enquiry and costs them the reply they are waiting for.

If you have a contact form you have never actually sent a message through — from a different machine, on a network you do not control, and then confirmed landed — you do not know that it works. You know that it renders.