Both sides of one real form journey, verified.
A browser submitted a uniquely tagged request through formheartbeat.com. The monitor then found the same marker in the destination inbox and recorded one matching message.
Operational evidence—not a mock-up and not a customer claim.
This evidence came from FormHeartbeat monitoring its own public request flow. It is a self-test, not a customer case study.
The record proves that this configured journey completed at the recorded time. It does not promise continuous uptime, prove compatibility with every form, or guarantee that no future lead can be lost.
One marker carried through four evidence stages.
Started 14 July 2026, 16:14:28 UTC; finished 14 July 2026, 16:14:48 UTC.
- 01Public page openedPassed
The monitor opened formheartbeat.com in a real browser and exposed the request form.
- 02Tagged request submittedPassed
A synthetic agency name carried the unique marker shown above.
- 03Browser success confirmedPassed
The expected receipt state appeared after 5.05s.
- 04Same marker matched in inboxPassed
An IMAP search found 1 matching destination message before timeout.
Before submission and after receipt.
The long-form screenshots are unedited browser captures from the same run. Select either image to inspect the full capture.


Why there is no public inbox screenshot: mailbox contents are deliberately excluded. The sanitized run record reports the IMAP result—one message matched the exact synthetic marker—without publishing unrelated email data.
The monitor also recorded a real setup mismatch.
Three minutes earlier, the browser could not find the configured form selector. The run was classified as FORM_CHANGED, inbox matching was skipped, and an email alert was sent.
This was a monitor setup mismatch, not a customer outage. Its value is diagnostic: FormHeartbeat did not turn an incomplete test into a healthy result.
- Browser stage failed during setup
- Inbox stage was explicitly skipped
- No healthy result was reported
- Founder alert was delivered
