--- title: "\"Failed to fetch\" — what your users are actually seeing" description: "Your app asked for something and nothing came back. Here are the five usual reasons, and how to tell them apart in two minutes." url: https://www.fomio.ai/blog/failed-to-fetch-what-your-users-are-actually-seeing published: 2026-08-28T18:00:00.431+00:00 updated: 2026-08-28T18:00:00.431+00:00 topic: error-translation words: 1966 --- # "Failed to fetch" — what your users are actually seeing Three words in a red box, and what each of the five likely causes looks like when you go looking. **In short:** - Those three words mean the request left your app and never arrived anywhere — no answer at all, not a rejection. - The most common cause for an app built this year is a sleeping database on a free plan. - If it works in the preview and breaks on the live link, a setting didn't get published. - You can narrow it down in about two minutes with a private window and the browser's Console tab. - Every one of these causes tells your users before it tells you. ### What does "Failed to fetch" mean in my app? It means the part of your app running in your user's browser asked for something and nothing came back at all. Not a refusal, not a permission error — silence. The browser waited, got no response, and gave up. So the problem sits between your app and whatever it was trying to reach, not inside your data. 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.[^6] ## 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.[^1] 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.[^2] ## 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.[^3] - **7** — Quiet days before a free Supabase project is paused [^3] - **10** — Days away before one developer found a blank screen and a paused project [^6] 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.[^6] > **Two honest caveats** — Waking it up isn't always instant. A Supabase issue from July 2025 reports a project taking far longer to resume than usual,[^5] and a discussion has someone waiting around half an hour, refreshing repeatedly, with no change.[^4] The popular prevention is a small automated task that quietly touches the database twice a week, since the window is seven days.[^7] That works. It's also a piece of plumbing you now own forever. ### 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.[^8] 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.[^8] ### 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.[^9] 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. **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. **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. **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. **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. **Paste this into your AI tool** ```text 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. ## Questions people also ask ### Does "Failed to fetch" mean my database is broken? Usually not. It means nothing answered at all, which points at the connection or the address rather than the data. If your database had rejected the request, you'd see a message about permission or a missing row instead. The most common causes are a free-plan project that paused itself after a quiet week, or a setting holding your database's address that didn't make it into the published version of your app. ### Why does my app work in the preview but not on the live link? Because the preview runs with pre-configured defaults that don't exist in the published version, according to a 2026 Lovable troubleshooting guide. When you publish, or move to a custom domain or a new host, the settings that tell your app where its database lives don't always travel. Copy every key from your project settings into your host's own settings screen — Site Settings → Environment Variables on Netlify, Settings → Environment Variables on Vercel — then publish again. ### How long does it take to restore a paused Supabase project? Often a couple of minutes. One developer restored theirs and had everything back almost immediately. But it isn't guaranteed: a Supabase issue from July 2025 reports a project taking far longer than usual to resume, and a separate discussion describes someone waiting around half an hour with repeated refreshes and no change. If you're in that position you aren't doing anything wrong — leave it and keep an eye on the dashboard. ### Can I stop my project pausing in the first place? Two ways. Paid Supabase plans aren't subject to automatic pausing for inactivity at all, per Supabase's own documentation. Otherwise the common workaround is a small automated task that touches the database a couple of times a week so it never goes quiet for seven days. It works, but it's a piece of plumbing you now maintain — and it doesn't tell you if it stops working. ### Only one user is reporting it. Is that still my problem? Probably not. If the app loads fine for you in a private window and for everyone else, the likely explanation is that user's own connection — patchy wifi, a tunnel, or an ad blocker being overly enthusiastic. Ask them to try a different network or turn off extensions. If a second person reports the same thing within a few minutes, treat it as a real outage and start with the database dashboard. ## Sources [^1]: Failed to fetch error after trying to add a user · Issue #20606 — supabase/supabase on GitHub (2024-01-21). https://github.com/supabase/supabase/issues/20606 [^2]: An error has occurred: Failed to fetch · Issue #12334 — supabase/supabase on GitHub (2023-02-10). https://github.com/supabase/supabase/issues/12334 [^3]: Project Pausing — Supabase Docs. https://supabase.com/docs/guides/platform/free-project-pausing [^4]: My Supabase Project is not Resuming after Pause · Discussion #38950 — Supabase on GitHub. https://github.com/orgs/supabase/discussions/38950 [^5]: resuming project taking a long time · Issue #37453 — supabase/supabase on GitHub (2025-07-25). https://github.com/supabase/supabase/issues/37453 [^6]: Supabase Free Tier Will Pause Your App. Here's the GitHub Actions Fix. — Level Up Coding (gitconnected) (2026-04-22). https://levelup.gitconnected.com/supabase-free-tier-will-pause-your-app-heres-the-github-actions-fix-8c1fd35b49ca [^7]: Prevent Supabase Free Tier Pausing (2026 Guide) — Medium (2025-12-31). https://shadhujan.medium.com/how-to-keep-supabase-free-tier-projects-active-d60fd4a17263 [^8]: Lovable Troubleshooting Guide: Fix the 10 Most Common Errors (2026) — AppStuck Blog (2026-05-04). https://www.appstuck.com/blog/lovable-troubleshooting-guide-fix-the-10-most-common-errors-2026 [^9]: Fix Lovable Supabase Errors — Hire Lovable Experts (2026-06-25). https://www.hirelovableexperts.com/backend/lovable-supabase-errors [^10]: New to WeWeb and Supabase — Getting this Error: TypeError: Failed to fetch — WeWeb Community (2024-02-07). https://community.weweb.io/t/new-to-weweb-and-supabase-getting-this-error-typeerror-failed-to-fetch/6897