Your Lovable app freezes or goes blank right after login: here’s why
Quick answer: Why does my Lovable app freeze or go blank after login?
In Supabase-based apps the classic cause is a deadlock in the login listener: AI-generated code waits for another Supabase request inside the callback that fires when the user signs in, and the two wait on each other. The app hangs on a spinner or blank page, often only after a refresh or a second login. Older versions of supabase-js are the ones affected.
The login form works. You see the “signed in” toast, or the URL changes to /dashboard… and then nothing. A spinner that never stops, or a white page. Sometimes it works the first time and freezes after a refresh. Sometimes it only happens when you come back to the tab.
What this looks like
- An endless loading spinner right after signing in
- A blank page after refreshing while logged in
- Works on the first login, freezes on the second
- The app hangs after you switch tabs and come back
- Logging out stops working, or a button just doesn’t respond
It happens in the Lovable preview too, not only on your live site. That’s a useful clue.
How this differs from a blank screen after deploy
If your app shows a white page immediately on load, before any login, and only on Vercel, Netlify or your own host, that’s a different problem: usually missing environment variables or wrong file paths. We cover that in blank screen after deploy. And if refreshing /dashboard gives a 404 instead of a blank page, see 404 on refresh.
This article is about the other case: the app loads, login succeeds, and then it gets stuck.
The usual cause: the login listener deadlock
Supabase apps register a listener that fires whenever someone signs in, signs out or their session refreshes. AI tools love to put “load the user’s profile” inside that listener, and to make it wait for the answer.
Here’s the problem in everyday terms. Imagine one key to a room. The listener is called while the auth system is holding the key. Inside, your code asks for another Supabase request, which also needs the key, and waits for it. The auth system won’t hand the key over until the listener finishes. The listener won’t finish until the request comes back. Both wait forever, and so does your spinner.
This isn’t a theory. A Supabase engineer explained the mechanism in auth-js issue #762 back in 2023, and for a long time Supabase’s docs warned against awaiting other Supabase calls inside this callback. Because it depends on timing (is a token refresh running? is another tab open?), it can work nine times and freeze on the tenth.
The good news: Supabase removed the lock behind it. Per the supabase-js 2.107.0 release (June 2, 2026), the client no longer uses that lock by default. So the question for your app is which version it actually runs. Projects created earlier, or with a pinned dependency, may still be on an older one. If you see this in your console, you’re hitting the lock:
Lock "lock:sb-api-auth-token" was not released within 5000msThat warning comes from a later recovery fix that breaks the lock after five seconds. If your login “works, but takes five seconds”, that’s the same problem.
The general fix is two things: run a current supabase-js, and keep the login listener short so slow work like loading a profile happens after it returns. The details depend on how your auth code is laid out, and that’s where AI rewrites tend to go wrong (more below).
Not sure which of these is your problem? The free health check looks at your live app in seconds, or request a free scan and we’ll tell you what we find.
Other causes with the same symptom
The profile row is missing, or RLS hides it
Many apps won’t render the dashboard until they’ve loaded a profiles row. If that row was never created for this user, or an RLS policy hides it, the query returns nothing, with no error, and the app waits forever for data that will never come. See Supabase returns an empty array.
A redirect loop between login and dashboard
The dashboard checks “is there a session?” before the session has been restored, sends you to /login, the login page sees a session and sends you back. The address bar flickers or the screen stays blank.
A crash in a component that only renders after login
The page you land on after login might have its own bug, for example reading a field from a profile that is still empty. In that case the console shows a red error, which is actually the easier case.
How to tell which one you have
Open DevTools (F12) before you sign in, then watch the Console and Network tabs:
| What you see | Most likely |
|---|---|
| No errors at all, the spinner just spins. Network requests to Supabase sit at “pending” or never start | Login listener deadlock |
| The “lock was not released within 5000ms” warning | Login listener deadlock (on a version that recovers) |
A request to profiles succeeds but returns [] | Missing profile row or RLS |
The URL keeps switching between /login and /dashboard | Redirect loop |
| A red error with a file name and line | A crash in a post-login component |
Also note when it happens: always, only after refresh, only on the second login, only after a tab switch. Timing-dependent freezes point strongly to the deadlock.
Why asking the AI to “fix the loading state” doesn’t work
When you tell Lovable “the app is stuck loading after login”, it sees a loading problem and adds a timeout, another loading flag, or a retry. The spinner might disappear, but the real cause is still there, and now it’s hidden. Each round trip costs credits and adds code. Because the bug is timing-dependent, the AI’s fix might even seem to work in the preview, then fail for real users.
That’s the loop we see most often: three or four “fixed it!” messages, and the app is more fragile than before.
Get it fixed
Stuck in the fix-and-break loop?
The $199 Fix: we find the real cause, fix it with tests, up to 5 issues, delivered as a pull request within 72 hours. Not fixed, full refund. Not sure it’s worth it? Get a free scan first.
FAQ
Why does it work in the Lovable preview sometimes but not always?
The deadlock depends on timing, such as whether a token refresh or another tab is using the auth session at the same moment. That’s why it can work several times and then freeze.
Is my data lost?
Almost certainly not. This is a frontend problem: the app is stuck waiting, but your database and users are untouched.
Why does refreshing make it worse?
On refresh the app restores the session from storage and may refresh the token at the same time, which fires the login listener exactly when the auth system is busy. That’s the moment the deadlock is most likely.
Will Lovable fix it if I ask again?
Often not. The symptom looks like a loading-state bug, so AI tools tend to patch the spinner rather than the listener. Describing the cause precisely helps, but untangling the auth flow usually needs a careful look.
Does this happen in Bolt or Cursor apps too?
Yes. Any app that uses supabase-js the same way, from any tool, can hit it, especially on versions before 2.107.0.
Related guides
- Lovable app shows a blank white screen after deploy? Here’s why
- Supabase returns an empty array but the table has data? It’s usually RLS
- Bolt.new app shows 404 when you refresh a page? Here’s why
- Is your Lovable app leaking user data? How to tell if your Supabase RLS is broken
- Google login sends users to localhost after you publish? Here’s the fix
- Stuck in a loop where every AI fix breaks something else? Here’s when to stop
Launching soon? Run through our launch checklist for AI-built apps: 14 checks, each linked to the full guide.