Lovable login not working means one of two things: you cannot get into your own builder account, or the people using the app you published cannot get into it. Check whose sign-in page refused first. If it is your app’s page, walk 5 project settings before touching code, starting with a custom domain missing from the redirect list.
Lovable login not working: your account or your users?
A failed sign-in belongs to you or to your customers, and the page that refused it says which. A Lovable page on a Lovable domain means your builder account. Your app’s own page, on its domain or a preview address, means your customers are locked out, and the cause sits in your project’s settings.
Before you change any setting, rule out an outage: whether Lovable itself is down is a one-minute check on Lovable’s status page. Clearing cookies and turning off ad blockers belong to the same half: they can get you into your own account and change nothing in your app’s settings. The rules for signup, reset and OAuth callbacks in general are written up under how each sign-in flow should work; this page stays on the settings that lock people out.
| Whose login | Where the refusing page sits | Where to look first |
|---|---|---|
| Your builder account | A Lovable page on a Lovable domain | The section on your own Lovable account, further down |
| Your customers | Your app’s sign-in page: on its custom domain, its lovable.app address or a preview, or a Replit-branded page when the app uses Replit Auth | The five settings in the next section |
On a phone the split is the same. When Lovable login is not working on an iPhone, ask which app the person opened: a customer on iOS refused by your published app is a customer-half case, and the five settings below apply as they would on a laptop.
Why is my app not letting me log in? Five settings, none of them code
Five settings can stop an app letting people log in without any code change: the published address missing from the redirect list, an app set to private, a confirmation email that never arrives, a Google client with a mismatched redirect, or an account that was created in a preview with its own user store.
We read Lovable’s, Supabase’s, Base44’s and Replit’s documentation on October 20, 2026 for every setting below, so the screens and wording are the builders’ own on that day. Builder screens move, so treat each click path as a place to look.
| What your customer sees | What it is | Where the setting lives | Fixable without code |
|---|---|---|---|
| Sign-in works in preview but breaks on the published app or custom domain | The published URL or custom domain is missing from the redirect URLs | Lovable Cloud: More, Cloud, Users, Auth settings, Advanced, Redirect URLs. Own Supabase: the URL Configuration page | Yes |
| A pop-up asking to request access, a message to ask the publisher for access, or an invalid login error with valid credentials | The app is set to Private or Invite only, or the person was never invited | Base44: the app’s visibility setting and its invited people. Lovable: the published app’s website access | Yes |
| Sign-up seems to work and the confirmation email never arrives | The hourly email limit, a spam folder, or a person who signed in again instead of signing up again | Lovable Cloud: email settings, Advanced, “Rate limit for sending emails” | Yes |
| Google sign-in ends in a redirect URI mismatch | Your own Google OAuth client, with a redirect URI that does not match exactly | Google Cloud Console, on the OAuth client. Nothing to change when Lovable manages the client | Yes |
| An account that worked in testing cannot sign in to the published app | Development and production keep separate user stores | Replit with Clerk Auth: a new sign-up on the published app | Yes, by signing up again |
Two causes look like a login fault without being a sign-in setting. Lovable’s credits page says that when a workspace has no credits left, “apps that use the built-in backend (Cloud) pause”; that case is covered under an app paused because the credits ran out. And when a customer did sign in and the first save failed, the fault is a database permission, described under the first write refused after sign-up.
If customers are locked out of a live app, these five settings check out, and you still cannot see where sign-in breaks, start with a free audit: a video call where we talk through with you where sign-in fails for your users and which cause to take on first. In our Production Hardening Sprint, our engineers review and fix signup, login, logout, password reset, email verification, and OAuth callbacks.
The published address is not on the redirect list
Lovable’s troubleshooting puts it in one sentence: “If sign-in works in preview but breaks on your published app or custom domain, these URLs are usually the reason.” The setting is an allow list. Lovable’s authentication docs describe “up to 50 URLs that auth providers are permitted to redirect to after authentication”, next to a Site URL, “the default URL users are redirected to after authentication when no redirect URL is specified.”
On the built-in backend, the same page says Lovable sets the Site URL to the published lovable.app address when you publish (a Site URL you set yourself stays unchanged) and adds a connected custom domain to the redirect URLs. When sign-in still fails, or the app runs on your own Supabase project, the page gives two routes: add the URL by hand under Auth settings, Advanced, Redirect URLs, or ask Lovable in the project chat to add your domain to the auth redirect URLs. Ask for that exact change by name.
On your own Supabase project, Supabase’s redirect URLs guide says “The Site URL in URL Configuration defines the default redirect URL when no redirectTo is specified in the code”, and the address your code asks for should match the Redirect URLs list. If only the preview address was ever added to that list, the live address is missing until someone adds it.
The same gap can run the other way: a preview’s confirmation link that lands live happens when the Site URL still points at production. Logins that break between a laptop and a server have their own causes (cookies, the session store, a callback left on localhost), covered under a login that fails once deployed.
The app is private, or the person was never invited
Base44’s login and registration page answers its own “invalid login” question with: “The most common cause is that your app is set to Private.” On a private app, only people who were invited or admitted through eligible SSO auto-admit can log in, and anyone else sees an invalid login error even with valid credentials.
Base44’s access page sets out three visibility levels:
| Visibility | Who can open the app | Sign-in |
|---|---|---|
| Public | Anyone on the internet | Not required |
| Private | Only invited people | Required |
| Workspace | Everyone in your Base44 workspace | Required |
A person who opens a shared link without access sees “a pop-up asking them to request access”, which a founder reading a support message easily takes for a login bug. The same login page lists three more causes: a wrong email or password, an email address never verified after sign-up, and an expired login session, where the fix is to log in again. Lovable has a similar control. Its publish page says “project access does not affect who can visit the published app”; website access does, and with Invite only, “Only people you add can visit the published app, after logging in” (Business and Enterprise plans can also limit it to workspace members). A visitor who is logged in but has no access “sees a message telling them to ask the publisher for access.” For Base44 problems beyond sign-in, see what to check when Base44 is not working.
Lovable Google login not working: whose OAuth client is it?
With Lovable Google login not working, the first question is who owns the Google OAuth client. In the managed mode on Lovable’s Google sign-in page, “Lovable manages the OAuth client, credentials, redirect handling, and related security updates for this flow”, with no Google Cloud Console setup, and connecting a custom domain needs no change in that mode.
Your own client is for teams that need OAuth under their own Google Cloud project, consent screen branding, custom scopes or specific compliance needs. The page sets two rules for your own client: “Redirect URIs must match exactly. Scheme, domain, path, and trailing slashes all matter”, and the client must be a Web application, because mobile or desktop client types do not work with Lovable’s redirect flow. After you add a custom domain, its redirect URL goes into Google Cloud Console as well.
On your own Supabase project, Supabase’s Google guide puts the project’s callback URL under Authorized redirect URIs and your application’s URL under Authorized JavaScript origins. On Base44, a custom Google client waits for Google to verify and approve the app, “which can take up to 5 days”.
The account was created in the preview, not the live app
Replit’s Clerk Auth page puts it in one line: “Each environment has its own user store.” An account made on the dev or preview app exists only in the Development environment and is not copied to Production when you publish, so the person signs up again on the published app.
The founder sees the email address in a list; the customer says the account does not work. Both are right, because they are reading different stores. Ask which address and which link the person used to sign up before you touch a setting. What else a preview does and does not share with production is covered under what a preview shares with the live app.
no-reply@auth.lovable.cloud: why your users’ confirmation emails never arrive
Authentication emails in a Lovable Cloud project come from the default Lovable Cloud Auth sender until the project sends from its own verified domain. When confirmations stop arriving, look at three causes: the hourly sending limit, a spam folder, or a customer who signed in again, which does not resend the email.
Lovable’s docs name that default sender without printing its address, so compare the From line a customer quotes with the one on a test sign-up of your own. For a customer, Lovable email verification not working means the confirmation never reached the inbox, so the account sits unconfirmed. A Lovable sign-up stuck on verifying email is waiting for a click on a link the person never received.
| Cause | What the customer sees | Where to change it |
|---|---|---|
| The hourly limit | Confirmations stop after many sign-ups at once | The per-project rate limit under Advanced, which you can raise once the project has email sending set up (managed email or a verified custom domain) |
| The spam folder | Nothing in the inbox | Send from your own verified domain |
| A sign-in instead of a sign-up | Still waiting for the email | Sign up again with the same email address, or add the person under More, Cloud, Users |
Lovable’s email authentication page says that if your app signs up many users at once and confirmations stop arriving, the rate limit “is the first thing to check”, and it publishes no default value for that per-project setting. Above it sits a workspace ceiling: “Lovable limits how many emails a workspace sends per hour, with separate limits for app emails and authentication emails”, 500 authentication emails an hour on Pro, 3,000 on Business and 10,000 on Enterprise.
For spam, Lovable’s advice is to ask users to check that folder first, “since emails from new domains often land there”. Its custom email setup adds SPF, DKIM and DMARC records for your domain, and “DNS changes typically propagate within a few hours, but may take up to 72 hours.” Its troubleshooting covers a domain stuck in “Pending” or “Verifying”, a status of Offline when required DNS records were changed, removed or expired after verification, and emails not sending. If emails are disabled for a project, authentication emails keep going out from the default Lovable Cloud Auth sender instead of your branded templates.
For a person stuck mid-sign-up, Lovable’s page says “Signing in again does not resend it”, while signing up again with the same email address can trigger a new confirmation; an account you create through Add user, Create new user in the Users view is confirmed automatically. Lovable also has an “Auto-confirm email” setting that signs users in without confirming their address. Turning it on lets new sign-ups in without the email, and it also lets a mistyped or throwaway address become an account whose owner you cannot reach.
Projects on your own Supabase project use Supabase’s email settings instead, and its default sender has limits of its own, explained under which Supabase email limit fired. The DNS side is covered under setting up SPF, DKIM and DMARC, and confirming each message was delivered under tracking whether each login email arrived. Base44 apps send from a default sender of their own. One aside: email-verify.lovable.app is a separate app published on Lovable’s domain and has nothing to do with your app’s emails.
Replit authentication: Replit Auth or Clerk, and where a login breaks
Replit authentication comes in two forms. With Replit Auth your users sign in with Replit accounts on a Replit-branded page; with Clerk Auth they create accounts inside your app, and the development and production environments keep separate user stores. Which one the app uses decides where a failed login is fixed.
| Replit Auth | Clerk Auth | |
|---|---|---|
| Who holds the accounts | Replit: a user is “creating or using an existing Replit account” | Your app: “no Replit account needed” |
| What the user sees | A Replit-branded login page | Your app’s own sign-up and sign-in |
| How you manage users | Tools, Users & Auth, Users tab: view all users, view user details, ban a user | The Auth pane’s Users tab: view, search and ban users, and switch between Development and Production |
| How it is added | Only through Agent; manual implementation is not supported | Through Agent, which creates the Clerk tenant and stores the credentials |
| Documented gaps | Not stated in Replit Auth’s docs | No phone sign-in, no multi-factor authentication for end users, sign-in providers limited to Google, GitHub, Apple and X, no organization tenants |
| Where a failed login is usually fixed | Replit’s side, or the domain list | The environment the account was created in |
Replit Auth works across development on replit.dev and published apps on replit.app and custom domains. Its troubleshooting covers a newly linked custom domain that does not work, and the fix is to republish, which refreshes the domain list held in the REPLIT_DOMAINS environment variable. Replit’s Clerk Auth docs list sign-in with a phone number as unsupported today, so a customer who asks for it is asking for something no setting will produce. For Clerk, rule out the user-store case described above first. What Replit gives a live app beyond sign-in is covered under what Replit gives a production deployment.
When it is your own Lovable account you cannot get into
Start in the browser: a fresh profile, popups and cookies allowed for Lovable, blockers and any VPN off. Lovable’s account page sends anyone who cannot log in to its password reset: enter the account email on the login page, click “Forgot password?”, and follow the link in the reset email. An account created with Google, GitHub, Apple or SSO has no Lovable password, so the reset email never comes and the reset happens at that provider.
A “Login denied due to suspicious activity” message comes from Lovable’s automated checks, and you cannot lift it yourself; the page says to retry from your usual network without a VPN or proxy, wait a few minutes because repeated attempts can extend the denial, then email support from the address you signed up with. Asked whether you can change the email you log in with, Lovable’s FAQ answers “Not directly”: you create a new account with the email you want and remix your projects into it. Getting a person on the other end is covered under reaching Lovable support with a ticket.
What to do in the next hour, and when to stop prompting
- 01 Decide whose login it is: the page that refused the person tells you whether it is your builder account or your customers.
- 02 Follow one real failed attempt from start to end: what the person saw, what the browser sent, and what the app recorded.
- 03 Walk the five settings without changing anything yet, and write down what each screen shows.
- 04 If requests come back looking fine and the app still acts signed out, look for a failure that reports success instead of a sign-in setting.
- 05 Tell customers something true and short: sign-in is failing for some accounts, you know, and what they can do meanwhile.
Step 2 is only possible if failures leave a trace, which is why logging failed sign-ins belongs in place before the next one. Step 4 is the case of an error that answers 200, where the response looks healthy and the app still treats the person as signed out.
Then stop prompting. Each of the five causes is a setting: a redirect list, an access level, an email limit, a Google client in Google Cloud Console, an account in the wrong user store. On Lovable, the project chat can change auth settings when you name the change, such as adding a domain to the redirect URLs. An open-ended “fix the login” prompt can leave the agent editing code instead, and then you have the same settings fault plus a change nobody reviewed. A broken live app has a first-hour order of its own, set out under the first hour of an incident.
Who can fix a login that locks customers out
You can, when the cause is one of the five settings and the builder’s screen shows it. The builder’s support is the route when your own builder account or an outage is the problem. A freelancer suits one broken flow with a clear way to reproduce it. An agency fits when sign-in is one part of a larger build you want a team to own over months. A service like ours fits when several flows fail at once, the emails need their own domain and provider, and nobody can say which settings production actually uses. Our view: if you can name the setting, fix it yourself today.
How to test sign-in and the login emails before your customers do
A sign-in setup is proven by trying every path on the published address, not in the preview. Sign up, confirm, log in, log out, reset a password and use Google sign-in as a new person, then try an expired link and a used one, and confirm each email arrived and the provider recorded it.
Of the 21 third-party apps we audited in June and July 2026, only 1, a healthcare FHIR hub, was credited with a real test suite, and even it skipped sign-up, login and the payment webhook. Those apps were picked for audit rather than drawn at random, so the count describes that set and is no rate for AI-built apps in general.
- 01 Sign up on the published address with a new email address and note when the confirmation email arrives and which sender it comes from.
- 02 Click the confirmation link, log out, and log in again.
- 03 Request a password reset, use the link, then open the same link again and expect it to be refused.
- 04 Request a new link, wait past the expiry your project sets, then open it and expect a refusal.
- 05 Sign in with Google on the platform address and again on the custom domain.
- 06 On Base44, open the shared link of a private app as a person who was never invited, and expect the pop-up asking for access.
- 07 In the email provider log, confirm each message was accepted and delivered.
Use new test addresses every time, never a real customer’s account. On Lovable Cloud, the “Email OTP expiration” setting decides how long a code or magic link stays valid, from 60 seconds to 24 hours, which sets the wait in check 4 when the link you test is a magic link. Account recovery should not lean on security questions, for reasons set out under why security questions make weak recovery, and the full list of authentication controls is in the authentication checklist.
In our Production Hardening Sprint, deliverable 1.1 is verified this way: exercise successful, rejected, expired, and reused-token paths for each supported flow. Deliverable 11.2 is verified by triggering each critical message type and confirming provider records and expected recipient delivery. None of the 123 deliverables on the published scope page names single sign-on, SSO, SAML or OpenID Connect, and OAuth appears once, in deliverable 1.1’s OAuth callbacks.
Common questions about users locked out of an app
How to reset a Lovable password?
On Lovable’s login page, enter your account email, click “Forgot password?”, then open the reset email and follow its link to set a new password; you are logged in once it is set. If you signed up with Google, GitHub, Apple or SSO, there is no Lovable password and no reset email: reset the password at that provider instead.
Why didn’t I receive a confirmation email?
A confirmation email that never came has gone to spam, been held back by the app’s hourly email limit, or was never resent because the person signed in again instead of signing up again. In an app built on Lovable Cloud, signing up again with the same email address can trigger a new confirmation, while signing in again does not resend it. When many people report it at once, the app’s owner should check the email rate limit and the sending domain.
Why am I frequently getting locked out of my user account?
Frequent lockouts usually trace back to one of three things: a session that expires early, a browser that clears or blocks the app’s cookies, or an automatic lockout after repeated failed sign-in attempts. A fresh browser profile with cookies allowed rules out the second. The app’s owner can tell the other two apart from the sign-in logs.
When should I get help with customers who cannot log in to my app?
Get help when paying customers are locked out and none of the usual settings explains it (the redirect list, app access, the email limit, the Google client, the user store), or when sign-in and its emails need to move to your own domain and email provider. AxonBuild starts with a free audit, a video call where we talk through the failed sign-ins with you and weigh up the likely causes.
Customers locked out of your live app?
When people cannot sign in, every hour costs signups and trust, and the cause is often a setting rather than the code. Bring it to an audit: we go over your sign-in setup with you, name the likely causes and tell you what to deal with first.
Book a free audit →
Free · 30 minutes · No code access needed