Users Can't Log In to My App: Your Account, or Your Customers

Two different problems share the words “login not working”, and they need opposite answers. Either you cannot get into your own builder account, or the people using the app you published cannot get into it. This page splits them in the first minute and then spends most of its length on the second one, because that is the half costing you customers and the half nobody on the first page of Google currently writes.

Every setting, path and limit below was read off Lovable’s, Replit’s, Base44’s and Supabase’s own documentation pages on 25 August 2026. None of those pages publishes a last-updated date, so the date attached to each fact here is the day it was read. Builder settings screens move often, so treat any navigation path as a place to look rather than a promise about today.

Customer login failures in AI-built apps are usually settings, not code. Five documented ones account for most of them: a missing redirect URL, an app access level, an hourly cap on authentication emails, a mismatched Google redirect URI, and test accounts that never existed in the published app.

Whose login is broken, yours or your customers’?

Two people type “login not working” and need opposite answers. If the sign-in page you cannot get past belongs to the builder, the problem is your account. If it belongs to the app you published, the problem is one of your project’s own settings, and your customers are the ones standing outside a locked door.

Tell them apart by which app started the sign-in and where the page that refused you sits. You opening the builder itself, on a builder domain, means your own account, and the mechanics for that sit further down this page. A person opening your app, on your app’s domain, a replit.app or preview address, or on the Replit-branded login page that Replit Auth sends your users to, means the second problem, and that is the emergency: every person who cannot sign in is a person who cannot use the thing they paid for.

Before you touch any setting, rule out the case where nothing about your project is wrong at all. Whether the platform itself is down or only your app is affected is a question a builder’s own status page answers in about thirty seconds, and it is worth those thirty seconds before you start editing configuration under pressure.

Five settings that lock your customers out, and none of them are code

Two things belong on this list without being settings. The first is the outage that happens for billing reasons rather than code reasons: a project frozen because a workspace ran out of credits takes everybody’s login with it, and no amount of reading auth settings will show you that. The second is the case where sign-in actually worked. If your customer got in and the first thing they tried was refused, you are looking at the error where the account is created and the very first write is refused, a database permission problem wearing a login problem’s clothes.

Your published app is not on the redirect list

This is the cause Lovable names in its own troubleshooting section, 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 mechanism is an allow list. After a person authenticates, something has to decide which address to send their browser back to, and the builder will only send them somewhere the project has explicitly named. On Lovable Cloud, the authentication documentation puts that list under Advanced in the auth settings, where a project may hold up to 50 “URLs that auth providers are permitted to redirect to after authentication”. Beside it sits a Site URL, the default destination after authentication when no redirect URL was specified. You reach both through the Users view, which the same page opens from the Cloud tab.

So a project built and tested entirely in preview has a redirect list describing the preview. Publish it, or point a custom domain at it, and the new address is not on the list. Nothing in your code changed and nothing in your code is wrong, which is why prompting the agent to fix the login produces edits that make things worse.

Projects wired to your own Supabase project work the same way from a different screen. Supabase’s redirect URLs guide describes a Site URL acting as the fallback when your code passes no explicit target, plus a separate allow list the requested address has to appear on.

The version of this that happens between your laptop and your server has different causes. The login that works on your laptop and dies on the deployed URL covers the cookie attributes, the in-memory session store and the callback still pointing at localhost, none of which are repeated here. A preview that is broken while the published app is fine runs the opposite way round and points at the builder rather than at your project’s settings.

Your app’s access setting is not what you think it is

Base44’s documentation is blunter about this than anything else read for this page. Its login and registration page lists the reasons a person gets a login error, and puts one first.

The most common cause is that your app is set to Private.

The same page explains what that means in practice: on a private app, only people who have been invited, or admitted through an eligible single sign-on auto-admit rule, can log in. Everyone else is being correctly refused, which is why the sign-in flow itself looks healthy in every log you check.

Base44’s access documentation sets the three levels out in a table of its own, and reading them next to each other is usually enough to spot the mistake.

Someone who follows a shared link to an app they have no permission for does not see a broken page at all; the documentation says “they see a pop-up asking them to request access”, which reads to a founder like a login bug.

Two more causes sit on that same page. A person who has “not verified their email address after signing up” cannot get in, which is the next section, and an expired login session produces a refusal the page answers by asking the person to try again.

Base44 is the one builder of the three whose own documentation names an app-level access setting as a login cause, and that is a statement about what the pages say rather than about the other products. On Lovable, the project access control described in its FAQ on 25 August 2026 governs who can open the project in the builder as a viewer or an editor, a different gate from your published app’s sign-in. On another builder, find that product’s own access page before assuming it works the Base44 way.

Nobody is getting the confirmation email from your app

A signup that appears to succeed and then goes silent has three separate documented causes on Lovable Cloud alone.

The first is a throttle. Lovable’s email authentication page documents a setting called “Rate limit for sending emails”, found under Advanced in the email settings, which caps how many authentication emails a project sends per hour. Its troubleshooting entry says when that bites: “If your app signs up many users at once and confirmations stop arriving, this limit is the first thing to check.” The page names the setting and, as read on 25 August 2026, publishes no default figure for it. Raising the ceiling means setting up email sending for the project first, either managed email or a verified custom domain. People search for a Lovable daily quota on email verification in those exact words, and on the date this was read the documented limit is hourly with no published value, so a daily quota figure from a forum thread maps onto nothing the vendor states.

The second is deliverability, and Lovable’s troubleshooting leads with it: ask the person to check their spam folder, because mail from a new domain often lands there. Lovable’s custom email setup configures SPF, DKIM and DMARC records for your own domain, and its timing note is the part people trip on: “DNS changes typically propagate within a few hours, but may take up to 48 hours.” One trap there is worth reading twice. If emails are disabled for a project, the same page says authentication emails keep going out from the default Lovable Cloud Auth sender rather than your branded templates.

The third is a person stuck partway. Lovable’s page says signing in again does not resend a confirmation, and that “the user can trigger a new confirmation email by signing up again with the same email address”. That is the sentence you can paste into a reply to a stuck customer today, and the page adds the operator-side version: an account added through the Users view is confirmed automatically.

If your project is connected to your own Supabase project rather than the built-in backend, none of that is where your setting lives. Lovable’s page scopes itself to the built-in backend and points own-Supabase projects at Supabase. On that side, Supabase’s SMTP guide documents that the default sending service refuses addresses outside the project’s own team until custom SMTP is configured, and that the built-in service and a newly configured custom one each carry an hourly ceiling. Which Supabase email limit actually fired, and what custom SMTP changes about each one, comes with its own published numbers and deserves reading in full.

One aside for anyone who arrived by searching these words: an email-validation tool built with Lovable, at email-verify.lovable.app, ranks on the same phrases and has nothing to do with your app.

Google sign-in stopped working

Before you open Google Cloud Console, find out whether you have anything in it. Lovable’s Google sign-in page describes a managed mode where “Lovable manages the OAuth client, credentials, redirect handling, and security updates”, with no Google Cloud Console configuration required. In that mode there is nothing on Google’s side for you to have broken, and a Google sign-in failure points back at the redirect list above.

Your own credentials are the other mode, and the page is clear about who needs them: teams requiring OAuth under their own Google Cloud project, full control of consent screen branding, custom scopes beyond the defaults, or specific compliance arrangements. Two details on that page cause most of the failures. The first is exactness: “Redirect URIs must match exactly. Scheme, domain, path, and trailing slashes all matter.” The second is the client type, where the page says to use a Web application OAuth client and that mobile or desktop client types are not compatible with its redirect flow.

The Supabase equivalent lives in the same corner of Google Cloud Console. Supabase’s Google sign-in guide says to add your Supabase project’s callback URL under Authorized redirect URIs, and your application’s URL under Authorized JavaScript origins. Two fields, two different values, and swapping them fails on Google’s page rather than in your app, which is why the app’s own logs look clean. If you cannot find where the client secret is supposed to live, where a key actually lives, and why the live app is missing it is the shorter read.

Base44 adds a wait that catches people out. Its login page says that after configuring a custom Google OAuth client, “Once you have completed the steps above, you need to wait for Google to verify and approve your app, which can take up to 5 days.” Switch from the built-in login to your own Google client on a Friday and you can spend the weekend debugging a queue.

The accounts you made while testing may not exist in the live app

This one is invisible from the outside, because nothing is misconfigured. Replit’s Clerk Auth documentation states it in one line: “Each environment has its own user store.” An account created while you were testing in the dev or preview app exists only in the development store, and an account created on the published app exists only in the production store. The page’s own FAQ answers the question a founder actually asks, which is why the account they made yesterday will not sign in to the published app: they have to sign up again there.

So the report you get is a person insisting their account does not work, and a founder who can see that exact email address in a list. Both are right, and they are reading two different lists. Before you change any setting, ask which address they used to sign up and whether it was the published app or a preview link.

The same split catches people well beyond login. What a preview actually shares with the live app, and what it does not covers the data and configuration that do and do not travel when you publish.

Login in Replit-built apps

Replit gives an app one of two authentication systems, and the reason login broke depends on which one you were given. Neither page read for this section states what either option costs, so this page does not answer that.

With Replit Auth, your users sign in with Replit accounts. The documentation says that when someone signs in to your app they are creating or using an existing Replit account, on a Replit-branded login page running the same flow used across replit.com. Two consequences follow. The accounts are Replit accounts, so you never hold the credentials, but you do administer them: the same page documents an Auth pane in the Project Editor where you can view all authenticated users, view a user’s details, track a user’s activity and ban a user from your application. And anyone who cannot get a Replit account cannot get into your app. The same page notes that Replit Auth can only be added by asking Agent for it, and that manual implementation is not supported, so there is no configuration file to inspect when it misbehaves. It covers development on replit.dev and published apps on replit.app and custom domains. The one documented failure worth knowing is a newly linked custom domain that does not work: the troubleshooting entry says to republish, which refreshes the domain list held in the REPLIT_DOMAINS environment variable.

With Clerk Auth, your app gets its own accounts and, as the documentation puts it, “Users create accounts within your app (no Replit account needed)”. Those people are not Replit users and exist only inside your app’s Clerk tenant. That independence is what most founders want, and it comes with a documented list of things it does not do today: sign-in with a phone number, multi-factor authentication for end users, full single sign-on provider coverage (the page names Google, GitHub, Apple and X as the ones supported), and Clerk’s organization and team-membership features. If your login problem is a customer who wants to sign in with a phone number, no setting will produce it.

Which one you have decides where you look. Replit Auth failures are Replit-side and domain-shaped. Clerk failures are usually environment-shaped, which is the separate user stores above. What Replit gives you for a production deployment, and what it does not covers the rest of that ground.

When it is your own Lovable builder account you cannot get into

This is the other half of the query, and the honest answer is that the documentation is thin. Searching the exact phrase on 25 August 2026 returns Lovable’s status page in the top organic slot, followed by community threads whose visible advice, read from the search snippet rather than the thread itself, is browser-side: turn off a VPN or Private Relay, allow popups and cookies, disable content blockers. That costs nothing to try in a fresh browser profile.

Beyond that there is a documented absence worth recording. The URL lovable.dev/faq/account/login looks like the right place to land, and on 25 August 2026 a request to it returned a 301 redirect to Lovable’s general FAQ. That FAQ runs to about sixty questions covering projects, publishing, billing, security and account management, and on the date it was read none of them covered being unable to sign in. The lovable.dev/faq/account/login path goes unlinked here for that reason: it no longer resolves to login content. What the FAQ does answer is the question people ask next, and the answer is a flat no: “Unfortunately, changing the email address directly is not possible at this time.”

Which leaves a person at the builder. The routes to a human, and what to put in the ticket so it is not bounced, decide how long a locked builder account stays locked, and they are worth reading before you write the first message rather than after the third.

What to do in the next hour, and when to stop prompting

Work in this order. It is short on purpose, because the useful moves take minutes and the expensive mistake takes one prompt.

1. Confirm which half you have, from which app started the sign-in. You opening the builder means your account. Someone opening your app, wherever its sign-in page is hosted, means your customers.
2. Read one real failure rather than guessing at five. Take one account that reliably cannot sign in and follow that attempt through: what the person saw, what the browser sent, what your app recorded. What to log so a failed sign-in leaves a trace you can read is the setup that makes this possible next time.
3. Walk the five settings in the table above, in order, without changing anything yet. Four of them are readable off a screen in under a minute.
4. Check whether sign-in is failing at all. If the request comes back looking fine and the app still behaves as though nobody is signed in, you are chasing the failure that answers 200 and tells you nothing rather than a login setting.
5. Tell your customers something true and short. “Sign-in is failing for some accounts, we know, here is what to do meanwhile” holds people. Silence does not.

Then the part that saves money. None of the five causes in the table is reachable by prompting. An agent editing your code cannot add your domain to a redirect list, change an app’s access level, raise an email ceiling, or move an account between two user stores. Ask it to fix the login anyway and it will do something, because that is what it does, and now you have a settings problem plus a diff you did not review. Someone who had built a working MVP moved the whole thing onto a different builder because sign-in kept failing, which is an expensive answer to what may have been one field on one screen.

There is a point where more prompting stops helping and starts costing you money. When your app is broken and people are paying for it, the first hour has an order to it worth knowing before you need it, and login is one of several ways to arrive there.

Common questions about users who cannot log in

Why is my app not letting me log in?

Check whether the refusal is coming from your own app or from the builder that hosts it. On a published app, the usual causes are settings: the app’s address missing from the redirect list, an access level that only admits invited people, or an unconfirmed email address. All three are readable off a settings screen.

If your customers can sign in and you cannot, that is your own account rather than the app. If nobody can, start with the redirect list.

What’s the most common cause of login failure?

Base44’s own documentation names one: “The most common cause is that your app is set to Private.” That is a statement about apps on Base44, made by Base44, read on 25 August 2026. It is not a universal ranking across every builder, and no vendor read for this page publishes one.

The shape of it generalises, though. Lovable’s own troubleshooting leads with the same class of cause: an address or access setting refusing people correctly, rather than a broken authentication flow.

Why is my Lovable login not working?

Split the question first. If Lovable’s own sign-in page will not let you in, that is your builder account, and Lovable’s status page plus a clean browser profile are the first two checks. If it is your published app refusing your customers, the cause is almost always a project setting.

For your own account the documented help is thin: Lovable’s general FAQ covered about sixty questions on 25 August 2026 and none addressed being unable to sign in.

Why does my Lovable signup stay stuck on verifying email?

An unconfirmed account usually means the confirmation email never arrived or has expired. Lovable’s documentation says signing in again does not resend it, and that the person can trigger a new one by signing up again with the same email address. Check spam first.

If it is happening to many people at once rather than one, look at the hourly cap on authentication emails instead of the individual account. Lovable’s own troubleshooting names that limit first.

Why did Google login stop working in my app?

Find out whose Google credentials are in play. When the builder manages Google sign-in, it owns the OAuth client and redirect handling, and there is nothing in Google Cloud Console for you to have broken. When you brought your own credentials, a redirect URI that does not match exactly is the usual answer.

Lovable’s rule is that scheme, domain, path and trailing slashes all matter. On Base44, a custom Google client also waits on Google’s approval, which its documentation says takes up to 5 days.

Why does sign-in work in preview but not on my published app?

The published address is missing from the project’s redirect list. Lovable’s authentication page says so directly: when sign-in works in preview and breaks on the published app or a custom domain, those URLs are usually the reason. Adding the live address and any custom domain fixes it.

A custom domain is a second address and needs its own entry, not just the platform-issued one. On Replit with Clerk Auth, the same symptom can instead be separate user stores.

What is Replit Auth, and do my users need a Replit account?

Yes, with Replit Auth they do. Replit’s documentation says a person signing in to your app is creating or using an existing Replit account, on a Replit-branded login page. Clerk Auth is the other option Replit offers, and its documentation says users create accounts within your app with no Replit account needed.

With Replit Auth the credentials are never yours, but the Auth pane still lists every authenticated user and lets you ban one, and failures tend to be domain-shaped. With Clerk you have your own accounts, and two environments to keep straight.

Can I turn off email confirmation to let people in?

You can, and it is a trade rather than a fix. Lovable’s auto-confirm setting signs people in immediately without confirming their address. Its own documentation calls that convenient while building and testing, and says that for a live app, leaving confirmation on ensures every account belongs to a real, verified address.

Turn it off under load and every signup succeeds, including the mistyped addresses and the throwaways. You have traded a queue of blocked customers for a list of accounts you cannot email.