Absence of confirmation is the signal: closing the inbox loop on a form monitor (week 2)

A reader of last week's build log left a comment I can't stop thinking about. He'd built an email-address probe once: it opened an SMTP session, issued RCPT, and got 250 OK back — for every address, including ones that don't exist. The bug was an off-by-one at the protocol layer: his code took over the socket without reading the server's 220 greeting, so every reply arrived one command late, and RCPT consumed the answer to MAIL FROM.

His summary: a check that never reads the first line of the conversation reports success forever, and it looks like a healthy week.

That's the scariest sentence I've read about monitoring, and it's the reason this week's build exists.

The question that started it

Week 1, I shipped a form monitor: every day it visits your site, finds your contact form, and submits a clearly-labeled synthetic test lead. The first comment on the post asked the obvious question:

Does your test lead check the inbox it actually lands in, or only that the form submit returned success?

Honest answer, then: only the submit. HTTP 200. The scariest failure mode — the form says "thanks" to the visitor while the notification email quietly lands in the owner's spam folder — was invisible to my own tool. I said so in the comments, because shipping a claim the engine can't back is worse than admitting the gap.

That comment thread became more valuable than the post. The same reader (Renhua) pushed on the design: closing the inbox loop properly needs a readable mailbox on the receiving side — a per-submission alias routing to a mailbox you control, matched on a token in the subject line. HTTP success, he pointed out, only tells you the first gate opened.

What I built this week

The loop is closed now, and I took the human route instead of the alias route:

• Every daily run, the engine embeds a unique delivery token in each synthetic test lead — a visible field, so the site's form plugin includes it in the notification email the owner receives.
• When the email lands, the owner opens their dashboard, sees the token, and clicks one button: "I received it."
• We record the confirmation timestamp. Done — the lead path is proven end to end: the form accepts a lead, and a human confirms it reached their inbox.

Why a human click instead of an alias into a mailbox I control? Because reading a customer's inbox means OAuth or IMAP access per customer, and that's a much bigger ask than a one-click confirm. His design is the cleaner automation; the click is the cheaper thing to trust. (He agreed, and then we spent two more exchanges geeking out about token lifecycles — burn-on-confirm, same-transaction atomicity, the accept-then-bounce case that no automated loop can fully close.)

The conclusion both designs converge on: absence of confirmation is the signal. If the test lead went out and nobody confirmed it, something between your form and your inbox is broken — even if every HTTP check in the world says green.

Then my own tool pulled the fire alarm on itself

Here's the part I didn't expect to write about.

I dogfood on my own site — formping.io monitors itself. Two days ago I checked the dashboard and found... nothing. No check rows from the morning run. The daily test email had arrived in my inbox perfectly, on time, with its token. The engine had run, submitted, delivered — and then silently written nothing to the database.

The cause: a batch insert where some rows had a confirm_token column and some didn't. PostgREST rejects mixed-key batches outright (PGRST102), and my code swallowed the failure and moved on. The submissions went out; the records never existed. If I sold "we verify delivery," my own system had just performed a silent one.

Fixing it took a one-line normalization. Finding it took dogfooding. This is the part of monitoring nobody puts on the landing page: your checks can fail in ways that look exactly like health. I got to feel that from the inside, one week after writing a comment saying HTTP 200 proves almost nothing.

Proof it works

Yesterday morning, the daily run fired at 05:17. The test lead landed in my inbox. I opened the dashboard, matched the token, clicked once:

✓ Inbox delivery confirmed · Nov 7, 13:48

One synthetic lead, one forwarded email, one human click — the whole path a real customer's contact form takes, verified on my own site first. (And re-verifiable any day: every run sends a fresh token.)

The numbers so far

I'll keep this honest and short. I sent 17 personalized outreach emails to web agencies whose own contact forms I'd tested (one hard-bounced on the recipient's side — their server refused the connection, which is its own kind of proof the problem is real). 16 delivered. Replies so far: zero. But five of those agencies clicked through and scanned their own domain — the pain landed, the call to action didn't. That's a copy problem, not a channel problem, so one more follow-up round goes out this week with a better ask.

A question for people who run contact forms

The trade I made — human confirmation instead of automated mailbox access — costs one click per day and buys proof without touching anyone's inbox. Would you click? Or would you rather grant a tool read access to your mailbox in exchange for zero clicks? Genuinely curious where the line is for people.

If you want to see what your own form looks like from the outside, there's a free 10-second read-only scan (no signup): formping.io/scan

Building this in public with an AI coding partner — every claim above matches what's actually running in production, including the embarrassing parts.