Your page is loading a build that no longer exists
A completely white page. No error, no spinner, nothing — and the browser console mentions a file that could not be found.
The HTML being served asks for JavaScript files that are not there. That happens when the page was cached from an older deploy, or when the build output went somewhere the server is not looking. The browser gets a blank page because the code that draws it never arrives.
What to do: Redeploy, then load the page in a private window. If the private window works and your normal browser does not, it is a cache and it will clear on its own — force-reload to confirm.
Your production build is missing its environment variables
Everything works in the builder's preview and breaks the moment you publish. Often the page loads but no data ever appears.
The published JavaScript still contains the placeholder for a value that should have been filled in when the app was built. These are baked in at build time, so setting them after the fact changes nothing until you rebuild — which is exactly why an app can be perfect in preview and dead once published.
What to do: Set the variable in your host's environment settings for the production deployment, then trigger a fresh build. Re-publishing without rebuilding will not pick it up.
Your app threw an error before it could start
A white page, with one red error in the browser console and nothing after it.
The app failed on its way up, so nothing was ever drawn. On an AI-built app this is most often a client being constructed with a configuration value that is missing — the code assumes it is there, it is not, and the failure happens before a single element renders.
What to do: The error message names what broke. If it mentions an undefined value or a malformed URL, you are looking at a missing environment variable in the published build rather than a bug in the code.
Your database is refusing to return rows, silently
The page loads, the layout is right, and the list is empty. No error in the console, no failed request — just nothing.
Row-level security decides which rows each visitor may read. When a policy is missing or does not match how your app signs people in, the database does not raise an error — it returns an empty result. So the page renders perfectly with nothing in it, and there is no error anywhere to search for.
What to do: Check that row-level security is enabled on the table AND that a policy exists which matches the signed-in user. An enabled policy with no matching rule blocks everything.
Your app cannot authenticate with its database
Nothing loads anywhere in the app, and the browser console shows repeated 401 or 403 responses.
Requests to your database are coming back rejected. The key the published app is using is either missing, wrong, or was replaced without the app being rebuilt. Nothing loads because every query is refused before it runs.
What to do: Check the database key in your production environment against the one in your project dashboard, then rebuild. A key changed in one place and not the other produces exactly this.
Your app is querying a table that is not there
An error mentioning a relation or table name, usually on the page that should show your data.
The database answered that the table does not exist. Almost always this means the deployed app is pointed at a different database project than the one you built against, or the migrations that create the table were never applied to it.
What to do: Compare the database URL in your production environment with the one you developed against. If they match, the migrations have not run against it.
Your server is returning an error
A plain error page, or a message from your host rather than from your app.
The page itself failed on the server, so nothing was ever sent to the browser. On an AI-built app this is most often a missing environment variable or a crash in code that runs before the page renders — neither of which is visible from outside.
What to do: Open your host's runtime logs for this deployment. The first error in them is the cause; everything after it is usually noise.
Your framework is showing its own error page
A generic error screen that does not look like your app and mentions your framework by name.
Your app crashed while rendering and the framework replaced it with a default error screen. The message it shows publicly is deliberately vague; the real error is in your server logs.
What to do: Open the runtime logs for this deployment and read the first error.
Your app is calling an endpoint that is not deployed
Most of the page works, and one feature — a form, a search, a save — does nothing at all.
The page is requesting one of its own API routes and getting “not found”. The route exists in your project but was not included in what got published — usually because the deployment is configured for a static site, or the build put the functions somewhere the host is not looking.
What to do: Check whether your host shows any functions for this deployment. If the list is empty and your app has API routes, the build output is being treated as a plain static site.
One of your own API routes is crashing
A feature that used to work now fails, often with a generic “something went wrong” message.
The page called its own backend and the backend failed. Whatever it needed — a secret, a database connection, a third-party service — is not there or is not answering. The browser gets an error with no detail in it by design.
What to do: Open your host's function logs and read the first error from that route. It will name the missing piece directly.
Your page loads insecure resources
One part of the page — an image, a font, a widget — is missing, and everything else is fine.
The page is served over HTTPS but asks for files over plain HTTP. Browsers block these silently, so whatever they were for simply does not work, with nothing visible to explain it.
What to do: Change those URLs to https, or host the files yourself.
A service worker may be serving you an old version
Your changes are live for other people but not for you, or the site works in a private window and nowhere else.
This app installs a service worker, which caches the site in each visitor's browser. When one gets stuck it keeps serving an old build to people who have visited before, while a new visitor sees the current one.
What to do: Open the site in a private window. If it works there and not in your normal browser, this is the cause — clear site data for the domain.