I found a bug in my own "never miss a lead" system
By Thiago Costa, ProTrade Automations
I build systems that catch leads other shops miss. So it stung to find out the chat widget on my own site had a bug that made it fail in every real browser, every single time. I have no idea how long it had been that way.
I'm writing this up because pretending it never happened would be worse than admitting it did, and because how I found it and fixed it is a better answer to "how do I know your systems actually work" than anything I could say on a sales call.
What was actually broken
The chat widget ran a quick health check before opening, to make sure it could reach the assistant behind it. That check was written using a request method that browsers treat as a real request needing its own security check, not the lightweight kind it was supposed to be. The server only allowed the actual chat method, so that check failed the security check every time, in every browser, before a single message could even be typed.
The tool I used to test it, a plain command-line request, doesn't enforce that same browser security rule at all, so every test I ran that way came back looking perfectly healthy. It took someone actually pasting me their real browser's own error message before the real cause showed up.
What I don't know, and won't pretend I do
I don't have a number for how many visitors hit that broken chat and just left. I'd like to tell you it was zero, or three, or thirty. I can't, because until this week I wasn't tracking outcomes closely enough to know. That's an uncomfortable thing to publish, but a made-up number would be worse than an honest gap.
It's also exactly why "pay only when it books" only means something if the booking actually gets measured, not just promised. That gap is next on my list to close, for my own site and for every shop I run this for.
What actually fixed it
Once I had the real browser error in front of me, the fix was small: swap the health check to a request type browsers don't flag, matching how the rest of the chat already talked to the server. Deployed, then tested it the only way that actually proves anything: sending a real message from a real browser and reading the real reply back, not just checking that the server returned a 200.
This is the whole point of "Never Miss a Job." A channel can look fine from the outside and still be silently dropping every single person who tries to use it. Catching that before it costs you real jobs, not after, is what the system's built to do. I just had to catch it on myself first.
Book a free 15-minute audit if you want someone to actually go check whether your own front door is doing the same thing to you.