askbowtie

How I find a dead form with askbowtie

Ben, founder of askbowtie

A form that quietly breaks is the worst kind of bug. Nothing errors, nothing goes down, the page looks fine. You just stop getting submissions and blame a slow week. Here's how I catch it fast instead, shown on our demo data.

The short version

askbowtie catches a silently broken form by joining behavior (rage clicks, dead clicks) with conversions. Here's the exact playbook I run.

  • The signature: steady clicks on a CTA, but downstream conversions collapsed. Demo data shows this pattern clearly in the quote form.
  • The finding: rage clicks on the submit button, a deploy note from 22 days prior, and a conversion drop that started that same day.
  • The cost: five tool calls, about a minute. The old way: weeks of emails and manual testing.
  • The fix: trivial once you have the selector. It's the not knowing that costs the money.

Why can't uptime monitors catch this?

Page returns 200, errors zero, traffic flat. Every monitor shows green.

How does askbowtie see what monitors miss?

Demo data: clicks hold steady while downstream conversion collapses 18% to 1.9%. That gap is the diagnosis.

What if it's just slow leads, not a broken form?

Traffic and clicks held flat in the demo data while conversions fell ninefold. Slow demand moves both lines; a dead form moves one.

Does this only work for forms?

Any CTA: buttons, links, checkouts, subscribe. Any click that should convert to action.

Why every monitor shows green

A silent failure means no error. The page returns 200, JavaScript doesn't throw, analytics sees normal traffic. The submit button just does nothing when clicked. The visitor clicks again, waits, leaves. They assume you got their message. You assume leads are slow this month. Nobody reports it.

askbowtie records every click with its CSS selector and every conversion, in the same database. A silent failure leaves a signature even when the error tracker is silent: either rage clicks (users expecting a response, getting none) or a CTA that clicks steadily but never converts. That gap is visible nowhere else.

The detection is the product. Once you have the selector and the deploy that broke it, the fix is usually trivial. It's the weeks of not knowing that cost the money.

Here's my playbook on demo data from kettlestone.com, a canonical test site. The numbers are the dataset's own; the scenario is staged on it.

38 → 4demo data: quote requests over 4 weeks
187demo data: sessions with rage clicks on the submit button
22 daysdemo data: duration from deploy to audit

How I found it in about a minute

what I actually typed

quote requests are way down but nothing's erroring. what's broken?

That's all I gave it. askbowtie ran the checks itself: the conversion drop, then rage clicks, then the exact broken selector, then the deploy that shipped the break. I never named a tool.

The playbook: five calls

Step 1: Confirm the bleed: 38 → 4 in four weeks

get_conversions { domain: "kettlestone.com", period: "28d" }.

Weekly demo data: 38, 31, 11, 4 quote requests. Traffic is flat. The drop is not a demand problem; something between the visitor and the system broke about three weeks ago.

Step 2: Check for frustration: 187 rage-click sessions

get_incidents { domain: "kettlestone.com", period: "28d" }.

Technical issues (js_error, http_5xx) are flat in demo data, confirming the silence. But the top incident: type rage_click, 187 sessions affected, concentrated on the /request-a-quote page. That is the fingerprint of a user expecting a response, hammering the same element because nothing happened.

Step 3: Name the element: the submit button, no error thrown

get_incident_detail { domain: "kettlestone.com", type: "rage_click", period: "28d" }.

Top signature in demo data: CSS selector form.quote-form button[type=submit] on /request-a-quote. No accompanying error message. That absence is itself diagnostic: users are clicking a button that fails silently, with nothing thrown to the console.

Step 4: Price it: 18% → 1.9% downstream

get_engagement { domain: "kettlestone.com", page: "/request-a-quote", period: "7d" }.

The demo data for cta:submit-quote section:

Steady clicks, ninefold conversion collapse. That is the definitive signature of a dead element, not a persuasion or market problem.

Step 5: Date it: deploy and first rage click, same day

get_notes { domain: "kettlestone.com" }.

Demo data shows a deploy note from 22 days ago: "swapped quote form to new async validation." First rage-click occurrence on form.quote-form button[type=submit]: the same day. Cause found: the new validator silently swallowed the submit on a blank optional field, exiting before firing the request. One line to fix.

The bottom line from the audit: the quote form has been dead for 22 days (demo data), here is the selector, here is the deploy that broke it, and it cost roughly 70 quote requests. Total investment: five tool calls and about a minute.

What you can ask about your own forms

Is anything failing silently right now?
`get_incidents`: all types (technical and behavioral) ranked by sessions affected. Behavioral types active while technical is flat = silent failure.
Which exact element is broken?
`get_incident_detail { type: "rage_click" }`: the CSS selector, page, and notably absent error message.
Is this frustration actually costing conversions?
`get_engagement` on the page: if engagement share holds but downstream conversion drops, the element is dead.
When did it break?
Line up `get_conversions` week-by-week with `get_notes` for the deploy that matches the conversion start date.
Are people still trying?
Steady clicks on the CTA in `get_engagement` while `get_conversions` shows output collapsing is the definitive pattern.
What did the silent failure cost?
Sum each demo week's shortfall against the 38/week baseline: 7 + 27 + 34, roughly 70 lost requests over the 22 days.

MCP reference (for agents)

The four core tools for a silent-failure audit, in order:

  • get_conversions { domain, period? } -> conversion counts week-over-week. Bleed shows here first: output falling while traffic holds flat. Establish the drop and its approximate start date before hunting causes.
  • get_incidents { domain, period? } -> active issues ranked by business impact. Behavioral types (rage_click, dead interactions) appear alongside technical classes (js_error, http_5xx, broken_asset). Behavioral types active while technical is flat = silent failure pattern.
  • get_incident_detail { domain, type, period?, limit? } -> signature-level drill: CSS selector, page, error message, request URL. For behavioral types, the error message is often absent, which is itself diagnostic.
  • get_engagement { domain, page, period?, limit? } -> per-section engagement (sessions, share percentage, downstream conversion rate). A dead element reads as: normal engagement share, near-zero downstream conversion. Compare prior period for the divergence.

Optional but often conclusive:

  • get_notes { domain } -> product log of deploys and changes. Line the first incident occurrence against the most recent deploy note to date the exact break.

Gotchas:

  • Downstream conversion is correlation, not attribution. Report "sessions that clicked submit converted at 1.9%", never "the button caused the drop", until deploy timing confirms causation.
  • Low viewed_sessions on a page makes every element-level rate noisy. Read the page's total session count before ranking elements.
  • Quiet error tracker plus active behavioral incidents is the silent-failure fingerprint. Quiet on both sides is genuine health. Always check both.

Recommended practice after every deploy: get_incidents over the hours since, and treat any new rage_click signature as an orphaned handler until proven otherwise. Run this full audit only if you skipped that and three weeks went by.

The old way was invisible: waiting for a report, manual testing, digging through SMTP logs. Now it's one question. Want to run this audit on your own site? Connect it to askbowtie.