How Do I Know if My App Is Broken for a Real User?

Right now, how would you know if your app just threw an error for someone using it? For most vibe-coded apps the honest answer is: you wouldn't, unless that person bothers to email you. The fix is error tracking, a small service that catches every crash on a real user's screen and reports it to you with the exact line that failed. You want it in place before your beta, not after.

Why you're flying blind

When you build and test your app yourself, you see errors immediately. They show up red in the browser console or in your terminal. So it feels like you would notice if something broke. But your users don't have your console open, and you are not watching over their shoulder. When the app throws an error on their screen, that error lands in their browser, which you never see. They get a blank page or a frozen button, shrug, and leave.

An AI agent building your app makes the happy path work. You asked it to "let users submit the form," and it did. You did not ask "and tell me when the submit fails for someone in a different browser with a slow connection and an empty field," so it didn't build that. Nothing is watching. That is the gap.

How to check whether you're affected

You almost certainly are, but confirm it:

1. Open your app and check whether anything reports errors back to you at all. Is there a Sentry, Highlight, or LogRocket logo in your dashboard? A line in your code that mentions Sentry.init or captureException? If not, nothing is catching client-side errors.
2. Do the coffee-cup test. Deliberately break something small in a copy of your app, click through it as a user would, then ask: did I get any notification? If the only way you found out was by looking, real users breaking it will be invisible to you.
3. Check your host's logs (Vercel, Netlify, Render). Server errors may be recorded there, but errors that happen in the user's browser usually are not.

The fix

1. Add an error tracker. Sentry is the common choice and has a free tier that is plenty for a beta. Create a project, pick your framework, and it gives you a few lines to paste in. This is the one-time setup.
2. Wire it into both sides. For a React or Next.js app, initialise it in the client so browser crashes are captured, and in your server or API routes so backend errors are too. The setup wizard walks you through both.
3. Trigger a test error on purpose. Sentry's guide includes a button that throws a fake error. Click it, then confirm the error appears in your Sentry dashboard within a minute. If it shows up, the pipe is connected.
4. Turn on email or Slack alerts so a new error pings you instead of sitting in a dashboard you never open. See how do I get alerted when my app goes down for the alerting side.
5. Add a fallback screen. When something does crash, users should see a calm "something went wrong, try again" message, not a white page. That is a separate, worthwhile fix covered in how-do-i-set-up-error-tracking-for-a-vibe-coded-app.

The trap to avoid

Do not settle for reading your host's logs and calling it monitoring. Server logs catch crashes that happen on the server, but a huge share of real-world breakage happens in the user's browser: a component that renders undefined, a button that silently does nothing, a form that fails only on Safari. Those never reach your server, so they never reach your logs. Error tracking that runs in the browser is the part that closes this gap. Logs alone leave you half-blind.

Where this fits

"It works on my machine" is true for almost every app right up until a stranger uses it differently than you did. Error tracking is what turns silent failures into something you can actually see and fix, which is most of what being beta-ready means. The free Readiness Report checks whether anything is catching errors in your project and flags the blind spots, and if you would rather have it set up and verified for you, that is what the Finishing Pass is for. For the deeper setup, start with how do I see logs from my app in production.