"Failed to fetch" — what your users are actually seeing

Someone messaged you a screenshot. White screen, or half a screen, and three words sitting in a red box.

That's the whole message. Not "the database said no." Not "the login was wrong." The request left the front end, and then nothing came back — no answer, no error, no anything.

This matters more than it sounds, because it tells you where to look. If your database had rejected the request, you'd have got a different message — one about permission, or a row not being found. Those mean the request arrived and was turned away at the door. This one means it never found the building.

One of the 2026 troubleshooting write-ups for Lovable builders puts it almost exactly this way: a failure before any response arrives, with the usual causes being a wrong or undefined project address, or a paused or deleted project.⁶

Why is it such a maddening message?

Because it's the same three words no matter what went wrong. That isn't your app being badly built — it's how browsers are designed.

When a request fails to complete, the browser deliberately withholds detail from the page. That's a security decision made years ago, to stop a malicious page probing around the internet and reporting back. So your app gets handed a generic failure, and dutifully shows it to your user.

Even the people who build database tooling find it unhelpful. On Supabase's own issue tracker, someone filing a bug in 2024 explains they were told to open a fresh report specifically because the message is so generic.¹ An older thread from 2023 has the same words appearing on the Supabase dashboard itself, in the corner of the screen, with nothing else to go on.²

What are the five things it usually is?

Roughly in order of how often I'd bet on each, for an app built with an AI tool and live in front of real people. The first two account for almost all of it.

1. Your database went to sleep

This is the big one, and it catches people who did nothing wrong. Supabase documents it openly: free plan projects that show low activity over a seven-day period get paused to save server resources, and projects on a paid plan are not subject to automatic pausing for inactivity.³

Your app is still online. Pages still load. But everything that needs data — logging in, the list, the dashboard, the thing users came for — reaches for a database that isn't answering.

A developer writing this up in April 2026 described coming back after ten days away to a blank screen: no error, no loading state, just nothing — then opening the dashboard and seeing a status they'd never seen before. They clicked restore, waited a couple of minutes, and everything came back. They'd had a live build out there the whole time.⁶

2. The address is wrong or missing in the published version

Your app knows where its database lives because that address is stored in a setting. When you publish, move to a custom domain, or hook up a different host, those settings don't always travel. The app then asks for data from an address that is blank or wrong.

The tell is specific: it works in the preview and breaks on the live link. One 2026 Lovable guide describes exactly that pattern — everything fine in the built-in preview, then errors, broken sections and blank areas on the live address, with nothing changed — and puts it down to the preview running on pre-configured defaults that don't exist in the published version.⁸

If you moved hosting, copy every key from your project settings into the host's own settings screen and publish again. On Netlify that's Site Settings → Environment Variables; on Vercel, Settings → Environment Variables.⁸

3. The server won't let your domain talk to it

Browsers enforce a permission list — CORS, which is just a list of which websites are allowed to request data from a given server. If your live address isn't on it, the browser blocks the request before it goes anywhere, and your app shows the same three words.⁹

Typically this appears the day you switch to your own domain, because the new address was never added to the allowed list.

4. Something upstream is having a bad afternoon

Your database host, your hosting provider, or another service your app calls. Nothing on your side changed. Check the status page of whatever your app depends on before you start rewriting anything.

5. The user's own connection

Real, boring, and worth ruling out. Patchy wifi, a train tunnel, an ad blocker being enthusiastic. If exactly one person reports it and the app is fine for everyone else, this is usually the answer.

How do I tell which one it is?

Open your live link in a private window — not the preview, not the editor. Then open the browser's built-in inspector (right-click, Inspect) and look at the tab labelled Console, which is where the page writes down its complaints.

1. 1
   A message about a missing or required address

   That's cause two — a setting that didn't get published. Copy your keys into your host's settings and publish again.
2. 2
   A message about the request being blocked from your origin

   That's cause three — the permission list. Add your live address to the allowed list on the server side.
3. 3
   The three words alone, after a quiet week

   Open your database dashboard and look for the word paused. Restore usually takes a couple of minutes.
4. 4
   Fine for you, still broken for users

   Check the status pages of the services your app depends on, then check whether it's one user or many.

Why didn't my app tell me before my users did?

Notice what every one of those causes has in common: your app doesn't tell you. It tells your users. The paused database is the clearest case — the project goes quiet, it sleeps, and the first you hear is a message from a customer, or more often no message at all, because most people who hit a broken screen just leave.

This is the gap Fomio was built for. It watches your app from the outside, the way a user would, and checks whether the thing actually works rather than whether the server is technically switched on. It reports one of three things: Working, Having trouble, or Down. You paste a link and it works out what to watch.

When something breaks, it emails you and says in plain language what likely went wrong. On the paid plans it also writes the prompt to paste back into the tool you built the app with — which is the step that usually costs an hour of guessing.

The free plan watches one app, checks every five minutes, keeps seven days of event history, and needs no card. Builder watches three, checks every minute, keeps thirty days, and includes the fix prompts. Pro watches fifteen, keeps a year, and gives your users a status page they can check themselves. Current prices are on fomio.ai/pricing.

Two things to be clear about, so you're not surprised: it tells you by email, not by text message or chat. And it won't stop your database pausing — it will just make sure you find out before your users do.

My published app shows "Failed to fetch" on the live URL but works in the preview. Check that the project URL and public key the app uses are read from environment settings, list every setting name the app expects at runtime, and tell me exactly which ones I need to add in my hosting provider's settings screen before republishing.

What should I do this afternoon?

Open your live app in a private window. If it's fine, check your database dashboard for the word paused — that's the failure quietly happening to a lot of apps built this year. If it's broken, work down the five causes in order.

Then set up something that checks the app for you, so the next time those three words appear, you're the one who sees them first.