Replit app stuck loading: a practical fix checklist

First separate Preview from the published app

Test the same action in Replit Preview and at the published URL. If both fail, the bug is likely in the application flow or a shared service. If Preview works but production spins, focus on production secrets, the published start command, allowed domains, database access, and the most recent deployment logs.

Use a private browser window for the public test. It removes an old session and shows what a first-time visitor actually experiences.

• Does the initial page render in Preview?
• Does the same route render at the published URL?
• Does the spinner begin before or after sign-in?
• Is the problem limited to one user role or route?
• Did it begin after a code, secret, domain, or database change?

Read the browser and deployment errors

Open the browser console and network panel before reloading the stuck page. Look for failed JavaScript, blocked requests, redirects, and API responses such as 401, 403, 404, 500, or 502. The request that remains pending or fails immediately often identifies the dependency keeping the screen in a loading state.

Then check Replit's logs for the same time. A browser error explains what the visitor received; a deployment log can show why the server crashed, rejected a request, or failed to connect to another service.

Confirm the app starts and listens correctly

A published web app must run the intended production command and listen on the port supplied by its hosting environment. If the process exits, binds incorrectly, or starts a development-only command, the public URL may return a gateway error or never become usable.

Check the deployment configuration, start command, build output, and the first lines in the runtime logs. Fix startup failures before debugging the page interface because the frontend cannot complete requests to a server that is not healthy.

Check production secrets and service connections

A Preview session can have access to values that the published app does not. Confirm that every required API key, database URL, authentication key, and service URL is available to the deployment using the exact name expected by the code.

Do not print secret values into public logs. Verify whether each variable exists, then use a safe health check for the connected service. If the app waits for a database or API call during startup, add a clear timeout and error path so a failed connection cannot create an endless spinner.

• Required secret names match the code exactly
• Production uses the intended API and database URLs
• The connected services allow the published domain
• Requests have timeouts and visible failure states
• A new publish contains the latest configuration

Trace authentication and redirects

If the spinner appears after login, inspect the full session flow. The app should clearly distinguish loading, signed out, signed in, and unauthorized states. A redirect loop can happen when the public domain is missing from the authentication provider, the callback returns to an old preview domain, or a user record is required but does not exist.

Follow one account from sign-in through the callback, session check, user-profile lookup, and final route. Confirm that each step either succeeds or displays a useful error. No promise should be able to reject while leaving the global loading flag permanently true.

Fix the loading state, not only the failed request

A resilient page sets loading before a request and clears it in a final cleanup path whether the request succeeds or fails. It should also show an error message with a retry action when the operation cannot finish.

Add sensible time limits around remote calls, avoid waiting for unrelated data before rendering the entire page, and test empty or unauthorized responses. A spinner is useful for a short wait; it should never be the application's only response to failure.

Republish and test the real user journey

After fixing the responsible layer, publish a fresh version and test the public URL rather than assuming Preview proves production is fixed. Use a new session, complete the main journey, and check the logs for new errors.

Verify sign-in, the affected route, its first API or database request, and at least one expected error state. This confirms both the original repair and the behavior visitors will see if a dependency fails again.