Contact Form That Failed: 61 Lost Enquiries

A broken contact form is a special kind of failure because you can’t see it.

There’s no error message. No site outage. No angry user — because the user believes the message was sent. The owner opens the site, sees it’s up, and assumes everything works. The only symptom is a phone that doesn’t ring, and that gets blamed on the season or the market.

This isn’t just about us. A law firm, an accounting practice, an engineering studio, a repair shop — they all take enquiries through a form, and almost none of them has ever checked whether that form works today. It was checked once, when the site went live, and trusted ever since.

How we found the failure in our own house

This is a self-report. Anparo is Petar’s own company, so what’s exposed here is our system, not somebody else’s — the story lands harder when the mistake is ours.

The swarm was building a lead magnet, a HACCP list generator, on ddd.anparo.hr. Email sending was being configured along the way. And that’s when it turned out the site’s existing contact form had been delivering nothing for weeks.

The site works. The form submits. The visitor sees “Thank you.” The notification reaches nobody.

The database held 61 enquiry records and zero sent notifications. Behind those 61 records stood 10 real people — the rest were repeated clicks on “Send,” because the form hung without responding so people kept trying again. One person pressed it twenty times. Another twenty-one. Not one of them emailed or called to complain. They simply left.

The cause was mundane: outbound SMTP port 587 is blocked from the server, so sending hung until the connection timed out instead of reporting an error. After switching to port 2525, sending takes 0.6 seconds instead of over 120. It was fixed the same day it was found, and every stored enquiry was pulled out of the database and handed over with contacts and messages. Among them was a property requesting a quote and one reporting a problem across several apartments.

Another site, a worse finding

When the same check was run against sec.anparo.hr, it came back worse. Since 29 July, the form had returned an error on every submission — 112 failed attempts. That form stores nothing in a database; it only sends email. Those submissions are irretrievably lost. That can’t be fixed, only admitted.

Along the way it also emerged that the domain’s SPF record didn’t authorise the service actually used to send the mail. Messages were getting through only because a DKIM signature existed — standing on one leg, with nobody aware of it.

Found by measurement, not by complaint

This is the point of the whole story. The form was in real use and real people had been sending enquiries for weeks. The failure wasn’t found because someone complained — nobody did, not a single visitor, not a single employee. It was found because an agent sent a real request instead of trusting the configuration.

And the configuration looked correct the entire time. Every setting was in its place. A check that read settings would have passed.

A monitor that stays quiet when everything is fine

The result is an agent that, twice a week — Mondays and Thursdays — sends a real request through the production form, as if it were a visitor, and reports if anything doesn’t get through.

Two decisions inside it are worth more than the code:

Response time is part of the check, not just status. Both failures presented as hanging rather than as an error: a blocked port, and a signup wait that no background process was there to finish. So a response longer than 8 seconds is treated as a failure, not as slowness.

The alert doesn’t travel on the channel being monitored. An alarm about broken email that arrives by email is useless. It reports to Teams, over a different connection. The monitor cleans up its own test records so it doesn’t clutter the enquiry list, and otherwise stays quiet.

What this means for a process owner

The port and the SPF record are evidence here, not the topic. The topic is a class of failure with no symptom — a process that quietly doesn’t run while looking to everyone like it does. The contact form is just the cheapest example; the same holds for every notification, report or forward that depends on a step nobody watches.

The difference between a system that’s monitored and one that’s assumed is measured in the enquiries you never received and will never know you had.

This article, like the agent it describes, was built by a swarm of DigitalBees agents. That’s deliberate: we’re not asking you to trust a promise that an AI agent can act rather than merely advise. This is the proof — the agent found a failure nobody reported.

If you want one test today: send yourself an enquiry through your own form and measure how long it takes for the notification to arrive. If it doesn’t arrive within a minute, you have the same problem we had — you just don’t know it yet.

Frequently asked questions

How can I check today whether my contact form actually works?

Open your own site as an ordinary visitor, fill in the form and submit it — and time it. If the notification doesn’t reach the person who answers enquiries within a minute, you have a problem. Check the spam folder too, on every address the notification is supposed to reach. And if the form takes more than a few seconds, that isn’t “slowness” — it’s an early sign of the exact failure we’re describing: a send that hangs instead of reporting an error.

Doesn’t uptime monitoring already cover this?

No. An uptime monitor checks whether the site is reachable — and the site was reachable the entire time. The form rendered fine, accepted input and printed a thank-you message. The failure was in the step after that, in delivering the notification, and no uptime tool can see it. That’s why our check submits a real request through the live form instead of reading configuration or page status.

If the enquiries are already lost, can anything be recovered?

It depends on whether your form writes the submission to a database before it sends the email. On ddd.anparo.hr it does, so we pulled all 61 records and handed them over with contacts and messages. On sec.anparo.hr the form stores nothing and only sends email — those 112 attempts have nowhere to be recovered from. The practical lesson: have every form record the submission locally before it tries to send anything. It’s a cheap change that makes the difference between “lost” and “recovered” real.