Three weeks ago I had a simple question: if the contact form on a
small business website breaks tonight, how long until anyone notices?
The honest answer for most sites: weeks. Months, maybe. Uptime
monitors say the site is fine (it is — the page loads). Analytics say
traffic is normal (it is — people still visit). The only thing that
changed is that form submissions quietly stop arriving. Nobody gets an
error message. The business just experiences it as "the phone got
quiet."
So I started building FormPing — a monitoring service that sends a
clearly-labeled synthetic test lead through every lead path on your
site (contact forms, phone links, email fallbacks) every day, and
emails you the moment one stops delivering. Not "is the page up" —
"does a lead actually get through."
WHERE IT'S AT
Week 3 of building, solo, evenings only — and week 1 of writing about
it in public:
- The free read-only scanner is live: paste any domain, get a 10-second audit of every way a visitor can reach you — forms, tel: links, email fallbacks. No signup — try it on your own site.
- The paid core is live: verify domain ownership with a TXT record, and my bot runs a real test lead through every path daily, with alerts.
- Pricing is deliberately simple: $29/mo (5 domains) and $79/mo (20 domains, white-label reports for agencies). Launch code for 50% off the first month.
- First dollar: $0. Zero customers, zero replies so far.
WHAT I DID THIS WEEK
Instead of sending another batch of template cold emails (about 80
sent across initial batches and follow-ups, 0 replies — brutal but
expected at this volume), I flipped the approach: I ran my own scanner
against the websites of web agencies — companies that literally sell
lead generation to their clients — and wrote each of them a personal
email about what the scan found on THEIR site. Broken form actions,
missing email fallbacks, forms routing through free third-party
relays, even WAF walls that block form-verification tools entirely.
17 went out across three nights — 8 on Monday, 8 on Tuesday, 1 going
out Thursday. Every email includes a screenshot and a link where they
can reproduce the result in 10 seconds.
EARLY SIGNALS FROM THE SCANNING ITSELF
Scanning agency sites taught me more about my market than any
competitor research did:
- The most common "failure" isn't a broken form — it's a form nobody can verify. JS-rendered, no action attribute, iframe-embedded. It probably works. Nobody can prove it.
- Several agencies that SELL lead tracking have their own lead paths running through free Gmail relays. Cobbler's children, everywhere.
- A surprising number block automated visitors at the firewall — which also blocks the tools that would tell them something's wrong.
THE PLAN
If the personalized scan outreach gets replies, this becomes the main
acquisition channel — it's repeatable, it's genuinely useful to the
recipient, and it's the product demonstrating itself. If it doesn't,
the pivot criteria are already written down.
ASKS
If you've ever lost a lead to a silently broken form — or you run an
agency and have a story about a client's form dying — I'd love to
hear how you found out (or didn't).
Building in public from zero. Numbers will be reported whether
they're good or ugly.
Drafted with AI assistance; every claim and number verified by me.
Top comments (12)
That off-by-one at the protocol layer is brutal — a check silently reporting healthy for a week is exactly the failure class this tool exists to catch.
On closing the loop: shipped a version today. One synthetic test per run with a unique token embedded in the submission, and the site owner confirms receipt with one click in the dashboard (we record the timestamp). I went with the human click instead of a per-submission alias into a mailbox I control — reading their inbox means OAuth/IMAP per customer, and the click reaches the same proof without me touching their mail. Your alias design is the cleaner automation; the click is the cheaper thing to trust.
the human click is the right call — it separates 'smtp accepted' from 'a person actually got it'. mine keys the token to the run id and burns it on first confirm, so a stale dashboard tab can't mark a dead run healthy.
Same goal, different mechanics — each daily run writes its own check row with its own token, and the confirm button only exists on the latest row. So a stale tab can only confirm a run that actually happened; it can't touch today's dead one. Your keyed-and-burned version is tighter against replays, though.
And you just earned your finder's fee: chasing your stale-tab scenario I found the actual hole — a failed submission was still minting a confirm token, so a dead run was confirmable as healthy. Fixed today: only accepted submissions mint one, and the confirm card only renders on passing rows.
the token lands in the row at insert and gets nulled inside the same update that stamps the confirmation, so the second click finds nothing to match against. a tab that outlives its row has nothing left to aim at.
Same-transaction burn, no window in between — that's the clean way to do it. This thread was better than most code reviews I've had. Week 2 log will have the first real confirmations from running the loop on my own site.
the failure row goes in the same transaction as the send, so a process killed mid-send leaves an unconfirmed row instead of an empty gap. the case my loop still can't close is a server that accepts at smtp then bounces later.
That's the case the click closes for free: accept-then-bounce means the owner never sees the test lead, never confirms, and the unconfirmed row itself is the alarm. Both our loops converge on the same detector — absence of confirmation is the signal. Good talking design with you.
the accept-then-bounce path is the one i trust least, since the smtp accept happens before a human has read anything. so the detector keys on the confirmation never arriving, not on an error being raised.
The Gmail relay thing doesn't surprise me at all. The failure I'd worry about most is the one where the form says "thanks" to the visitor but the email quietly lands in the agency's spam folder, because nothing on the site side looks broken. Does your test lead check the inbox it actually lands in, or only that the form submit returned success?
Exactly the right question, and the honest answer: today the paid check confirms the form accepts the submission (HTTP success) — it does not confirm the email lands in the inbox. The "thanks page but spam folder" case is the scariest failure mode, and the current design can't see it.
The TXT record only proves ownership so I submit to opted-in sites — it doesn't close the inbox loop.
Closing that loop is the next build: a unique token in each test lead, plus a confirmation signal back (a one-time forward, or a forwarding rule the user sets once). I'd rather admit the gap in a comment than ship a claim the engine can't back.
checking the inbox is the right instinct, and the layer below it is worse: i
wrote an address probe that opened an SMTP session and issued RCPT, and it
returned 250 for every address including ones that don't exist - taking the
socket over meant the 220 greeting was never read, so every reply arrived one
command late and RCPT consumed the answer to MAIL FROM. a check that never reads
the first line of the conversation reports success forever, and it looks like a
healthy week.