The report button that tells you your site is broken before customers give up

Picture a small SaaS tool on a Tuesday afternoon. A deploy goes out, a config value is wrong, and the sign-up form starts throwing an error for everyone. Nothing crashes loudly. The server is up, the homepage loads, and the dashboard looks fine to the team because they are already logged in. For three hours, every new visitor hits a dead form, shrugs, and leaves. The owner finds out that evening — from a single annoyed tweet. This is the quiet way websites lose money. Not a dramatic outage, but a small break that only visitors can see, and visitors almost never tell you. They assume someone already knows. They assume it is their own connection. Mostly, they just move on. ## The problem: you find out last When something breaks on a live site, the people who notice first are the ones least able to fix it: your visitors. Between them and your developers sits a wall of friction. To report a bug, a visitor would normally have to find your contact page, figure out which email to use, describe a technical problem in their own words, and remember which page they were on. Almost nobody does all of that for a company they do not work for. So the report never arrives. Your monitoring might catch a full server outage, but it rarely catches a broken button, a form that fails only in Safari, a checkout that errors only when a coupon is applied, or an image that 404s on one product page. These "partial" failures are common, they are invisible from the inside, and they are exactly the ones that cost you sign-ups and sales. The gap is not technical. It is human. You need to make reporting a problem so easy that a mildly annoyed stranger will actually do it. ## The fix: a pre-filled "Report a problem" button Add a small, always-visible **Report a problem** button to your site — in the footer, in a corner, and especially on your error and empty-state screens. Instead of pointing to a contact form, it is a `mailto:` link that opens the visitor's own email app with the message already written for them. The visitor clicks once. Their email app opens with your dev team in the To field, a clear subject, and a short template body. They type one line about what went wrong and press send. That is the whole interaction — no forms, no logins, no account. Here is the link behind the button: ```html <a href="mailto:[email protected]?subject=Site%20problem%20reported&body=What%20I%20was%20doing%3A%0AWhat%20went%20wrong%3A%0A%0APage%3A%0ABrowser%3A"> Report a problem </a> ``` The generator on this site builds and encodes that link for you, so a stray space or bracket never breaks it. ## What the report should contain The value is in the pre-filled body. A blank "email us" link gets you "it doesn't work." A pre-filled report gets you something you can act on. Prompt for the three things a developer always asks: - **What the visitor was doing** — the action that failed. - **What went wrong** — the error text or what they expected to see. - **Context** — the page URL, and ideally the browser and time. If the button lives inside your own app, you can fill the context automatically. A tiny script can drop the current URL, the browser string, and a timestamp straight into the body before the email opens, so the visitor only writes one sentence: ```html <a id="report" href="#">Report a problem</a> <script> const a = document.getElementById('report'); const body = 'What I was doing:\nWhat went wrong:\n\n' + 'Page: ' + location.href + '\n' + 'Browser: ' + navigator.userAgent; a.href = 'mailto:[email protected]' + '?subject=' + encodeURIComponent('Site problem: ' + document.title) + '&body=' + encodeURIComponent(body); </script> ``` Now every report arrives tagged with the exact page and environment. Your developer can often reproduce the bug before replying. ## Setting it up in five minutes 1. Pick the address that should receive reports. A shared inbox or alias like `dev-team@` works well, so the whole team sees it. 2. Build the link in the generator: set the recipient, a clear subject such as "Site problem reported," and a short body with the three prompts above. 3. Copy the HTML snippet and paste it into your footer and your error page. 4. If it lives inside an app, add the small script so the URL and browser fill in automatically. 5. Send yourself a test report to confirm the draft opens correctly. No backend, no third-party form service, no new bill. The `mailto:` link is part of HTML, so it works on a static site, a landing page, a help-desk article, or a full web app. ## What it saves you The saving is in **time-to-detection**. Suppose your site gets 1,000 visits a day and a form quietly breaks at 2 p.m. Without a report path, you might learn about it that night — six hours and a few hundred lost sign-ups later. With a one-click report button, the first confused visitor pings your team within minutes. You lose a handful of sign-ups instead of an afternoon of them. There is a support saving too. Vague "your site is broken" emails cost a support person several minutes each just to chase down which page and browser. A pre-filled report answers those questions up front, so triage drops from minutes to seconds. And because reporting is effortless, more people do it — turning a silent problem into a steady, honest signal about what is actually breaking in the wild. It also protects trust. A visitor who can report a glitch in one click feels heard, even when something is broken. A visitor who hits a dead form and has no way to tell you simply leaves and remembers your site as the one that did not work. ## Make it even better - Put the button on your **404 and error pages**, where frustration is highest and a report is most valuable. - Use a **subject tag** like `Site problem:` so a simple inbox rule routes every report to the right channel. - Keep the address **obfuscated** on public pages so spam bots do not harvest it — a small script that assembles the link on click is enough. - Pair it with a visible status note ("Having trouble? Tell us") so people know the button is there for them. ## Key takeaways - Your visitors see breakage first, but almost never report it — the friction is too high. - A pre-filled `mailto:` "Report a problem" button removes that friction: one click, one sentence, sent. - Auto-fill the page URL and browser so every report is reproducible. - It needs no backend and no budget, and it cuts your time-to-detection from hours to minutes. Build your own report button in the [generator](/#generator), or copy the setup below to start.