New lead alerts that actually arrive, and the bug that silently ate them

The form worked. The lead was in the CRM. The email that was supposed to tell someone about it never showed up, and nothing anywhere said so.

What the owner saw

A painting company we work with called about a quote request a customer mentioned on the phone. The customer said they had filled out the form days earlier. We looked. The lead was sitting in the CRM, right where it should be, with a timestamp. Nobody had been told. No email, no text, no Slack message.

That is the worst kind of bug. Nothing errored. Nothing looked broken. The form said thank you, the record was saved, and the one step that turns a record into a phone call just did not happen.

What was actually going on

Here is the sequence a form goes through when someone hits submit. The website sends the details to the server. The server saves the lead to the database. The server sends a reply to the website so it can show the thank you page. Somewhere in there, the server also tells the alert service to send the notification.

The code was written in a very common way: save the lead, send the reply to the visitor right away so the page feels fast, and let the alert go out in the background. On a traditional server that works fine, because the server keeps running after the reply. On the kind of hosting most modern sites use, the server is not a machine that stays on. It is a small program that wakes up for each request and is allowed to stop the instant it has replied.

So the alert was being handed off a fraction of a second after the reply went out, and a fraction of a second was sometimes enough for the hosting to shut the program down before the alert was sent. Sometimes the alert made it. Sometimes it did not. There was no error either way, because from the server's point of view nothing failed. It was simply told it could stop, and it stopped.

How we found it

We did not find it by reading the code. We found it by submitting a lead ourselves and watching each step happen in the logs, the running record the hosting keeps of what the server did. The save showed up. The reply showed up. The alert request never appeared. Then we submitted again and it did appear. The inconsistency was the clue. A bug that happens every time is in the logic. A bug that happens some of the time is almost always about timing.

Once we knew where to look, the explanation was a single line: the alert was started after the reply instead of before it finished.

What we changed

• The alert goes out before the reply completes. The server now waits until the alert has been accepted by the email service before it tells the website the submission is done. The visitor waits a fraction of a second longer and never notices. The alert always gets its turn.
• Every alert writes its own record. Sent, failed, or never attempted. If an alert fails, the lead now shows a visible mark in the CRM, and the morning brief for that business lists any lead that nobody was told about.
• We checked every other place the same pattern lived. It was not only the lead alert. The same habit of doing work after the reply showed up in a few other spots, including a booking confirmation. Same fix, everywhere.

Why we test with a real lead now

Before launch, and after any change to the form or the server, someone on our side fills out the real form on the real site with their own phone number, and we confirm three things: the record is in the CRM, the alert arrived on the right person's phone, and the timeline on the lead shows both events. Not a test tool. Not a simulated request. The actual form a customer will use.

It takes two minutes and it is the only test that proves the whole path. Unit tests, the small automatic checks developers write, can tell you a function works. They cannot tell you the hosting shut down before the function finished.

What this means for you

If your website has a form, ask whoever built it a simple question: when was the last time you submitted it yourself and watched the alert arrive? If the answer is a shrug, the alert may be working, or it may be working most of the time, and you will not know which until a customer tells you.

A lead alert that arrives every single time is the whole point of the CRMs we build, and this bug is why every one of them now ships with a logged, tested, and visible notification path.

Questions people ask