Fixing a Replit app stuck after Clerk sign-in

The product context

The project used more than one Replit application and Clerk for authentication. A user needed to sign in once, pass through the landing experience, and reach a protected comparison workflow without being asked to authenticate again.

The client and product are intentionally unnamed in this case study. The symptoms, investigation pattern, and verified production outcome are real, while private business details and credentials remain confidential.

What was going wrong

After sign-in, the application could remain on an endless loading screen. An affected account could also receive a message that it did not have a valid user record. At different points, Preview and the published URL behaved differently, making it easy to mistake two environment problems for one application bug.

The useful question was not simply why the spinner appeared. It was which step had failed between Clerk authentication, application-level user provisioning, domain validation, redirect handling, and the final protected route.

• Endless spinner after authentication
• Valid Clerk session but missing application user access
• Preview and published URLs producing different behavior
• More than one Replit application sharing the sign-in journey
• A protected destination route that needed a reliable redirect

How I isolated the failure

I treated Preview and production as separate environments and tested the shortest important journey first: open the public landing page, sign in, resolve the user, and reach the protected tool. This prevented a Preview-only failure from masking progress on the live route.

I then checked the Clerk domain and proxy configuration, confirmed that the required keys existed in both Replit applications, reviewed the invitation and user-record path, and followed the redirect into the destination application.

The focused repair

The authentication settings were aligned with the relevant Replit domains, and the expected Clerk values were added to both application environments. The user invitation path was refreshed so the test account could be evaluated cleanly instead of inheriting an earlier failed state.

For the demonstration journey, the route was simplified around the actual goal: authenticate once and continue to the comparison tool. The applications were republished after the configuration changes so the live test used the current settings.

• Align the authentication provider with the public domains
• Confirm matching environment-variable names in each application
• Retest with a clean invitation and user record
• Remove unnecessary redirects from the primary demonstration path
• Republish before judging the production result

The verified result

The published application stopped spinning and the live journey could reach the intended comparison workflow. That confirmed the production path was no longer blocked by the same loading failure.

Preview still needed its own domain handling, so it remained a separate follow-up rather than being presented as a fully resolved production problem. Keeping that distinction made the handoff more accurate and protected a working live route from unnecessary changes.

What this means for similar Replit apps

When a Replit app hangs after login, check identity, product-level user access, allowed domains, redirect URLs, environment values, and the published route as separate layers. A spinner is a symptom; the missing transition usually sits underneath it.

The fastest repair is normally a narrow, repeatable journey tested with one clean account. Once that route works, expand the test to additional roles, invitations, preview domains, and failure states without changing the successful path blindly.