Start watching free

Guides · Seeing your users’ errors

How to see the errors your users hit

Your app works when you try it. Then a user writes “it’s broken”, with no details, or, more often, doesn’t write at all and leaves. The error happened on their device, and nothing brought it back to you. Here is where errors live in an app built with AI, and how to see them.

Three places errors happen

WhereWhat breaks thereWhere you can see it
The visitor’s browserA page crashes or goes blank, a button does nothing, a request to your backend fails.Only in that browser’s console, unless a monitoring script sends it to you.
Your backendAn edge function or API route throws, the database refuses a query, a secret is missing.Your backend’s logs: Supabase’s Logs and each edge function’s logs, or your host’s function logs.
Services you depend onA payment fails, a webhook is rejected, an email bounces, an AI call runs out of credit.That service’s dashboard: Stripe lists every API request and webhook delivery, with failures.

The first row is the one most people never see, and the one most users hit: in an app built with Lovable or Bolt, most of the logic runs in the browser.

Read an error in your own browser

When you can make the problem happen yourself, the browser tells you a lot.

  1. Open the live app (not the preview) in Chrome, Edge or Firefox.
  2. Right-click anywhere and choose Inspect, then the Console tab. On a Mac, Cmd+Option+J opens it directly in Chrome.
  3. Do the thing that breaks. Red lines are errors.
  4. Open the Network tab and do it again. Red rows are requests that failed; click one, and its Response often holds the real reason.

Then give your AI all of it, not a summary:

On my live app, when I [WHAT YOU DID], [WHAT HAPPENED]. It should [WHAT YOU EXPECTED].

The browser console shows:
[PASTE THE RED ERROR, the whole thing]

The failing request in the Network tab:
[METHOD AND ADDRESS, the status code, and the response body]

Find the cause in the code before changing anything, and tell me what it was. If the cause is a setting outside the code (a missing secret, a database policy, a dashboard setting), tell me exactly where to change it.

Check the backend’s logs

  • Supabase: the dashboard’s Logs section covers the API, the database and sign-in; each edge function has its own logs under Edge Functions. An error there at the time a user complained is usually the cause. See “Edge Function returned a non-2xx status code”.
  • Vercel, Netlify, Cloudflare: each project has logs for its functions or workers.
  • Stripe: the dashboard’s developer section lists API requests and webhook deliveries. A webhook that keeps failing is the classic “I paid but nothing happened”: here is that one.

Ask users the right way

When someone does write, “it’s broken” is hard to act on. A short feedback link that asks three things gets you most of what a developer would ask: what were you trying to do, what happened instead, and on which device. A screenshot helps more than a description.

Stop relying on luck: monitor it

The only way to see the first row of that table for every visitor is a small script in your app that reports errors as they happen. Whatever you choose, look for:

  • Errors and failed requests from the browser, not only crashes: a request your backend refused is often the real problem.
  • Grouping, so a thousand visitors hitting one bug is one problem, not a thousand emails.
  • What the visitor did just before, so you can reproduce it.
  • Words you can act on: a stack trace is perfect for an engineer and useless for most people building with AI.
  • Privacy: emails, tokens and card numbers removed before anything leaves the visitor’s browser.

The tools differ mostly in who they are written for. Sentry, PostHog, Lovable’s own monitoring and Vigilia, compared.

What Vigilia adds

Vigilia watches errors, failed and slow requests, dead buttons and downtime on your live app, from every visitor. Each new problem arrives in plain language, with who it affects and a fix prompt written for the tool you build with, and your AI can read it directly over MCP. When you mark it fixed, Vigilia watches real visitors and tells you whether the fix held. Errors from your own laptop and preview links are recorded but never alerted.

Know before your users tell you

Vigilia watches your live app, explains what breaks in plain language, hands your AI the fix, and confirms it held with real visitors. One app is free.

Read next