Which part of sign-in is failing
Login problems feel like one fault and are usually one of five. A person signs up and the confirmation email never arrives. The email arrives and its link opens the wrong site. The button for signing in with Google or another provider works for you and rejects everyone else. A user gets in and is signed out again on the next page. Or the user signs in without trouble and finds an empty account.
Each of these has its own cause and its own fix, so the first job is to see the failure yourself. Use a private browser window and an email address the app has never seen, on a different email service from your own. Go through sign-up, confirmation, sign-out, sign-in and password reset on the live site. Write down the step where it stops and the exact message on screen, then find that step in the table.
Where login fails, and what to look at
- What the user reports
- The confirmation or reset email never arrives
- Usual cause
- The app sends through a default sender meant for testing, or mail from your domain is not set up to be trusted
- What you can check
- Send to addresses on two or three email services and look in spam
- What the user reports
- The link in the email opens a preview, localhost or an error page
- Usual cause
- The site address saved in the sign-in settings is still the one used while building
- What you can check
- Hover over the link in the email and read the address before you click
- What the user reports
- Signing in with an outside provider works for you and fails for others
- Usual cause
- The provider connection is still in a testing state, or it lists only the preview address
- What you can check
- Try it with an account that has no connection to the project
- What the user reports
- Signed in, then signed out after a refresh or by the next day
- Usual cause
- The session is not being stored or renewed, or the live site answers at two addresses
- What you can check
- Sign in, refresh, close the browser and reopen it, noting when you are asked again
- What the user reports
- Signs in and sees a blank account or a permission message
- Usual cause
- The rules that let a user read their own records were never finished
- What you can check
- Create a record in a new account and see whether it is still there after signing back in
| What the user reports | Usual cause | What you can check |
|---|---|---|
| The confirmation or reset email never arrives | The app sends through a default sender meant for testing, or mail from your domain is not set up to be trusted | Send to addresses on two or three email services and look in spam |
| The link in the email opens a preview, localhost or an error page | The site address saved in the sign-in settings is still the one used while building | Hover over the link in the email and read the address before you click |
| Signing in with an outside provider works for you and fails for others | The provider connection is still in a testing state, or it lists only the preview address | Try it with an account that has no connection to the project |
| Signed in, then signed out after a refresh or by the next day | The session is not being stored or renewed, or the live site answers at two addresses | Sign in, refresh, close the browser and reopen it, noting when you are asked again |
| Signs in and sees a blank account or a permission message | The rules that let a user read their own records were never finished | Create a record in a new account and see whether it is still there after signing back in |
Confirmation and reset emails that never arrive
Most sign-in services can send confirmation and reset emails for you without any setup. That built-in sender is commonly meant for trying things out. It tends to allow only a small volume, and its messages come from an address that has nothing to do with your business, so inbox providers are more likely to filter them. It holds up while you are the only person signing up and falters when a group of testers arrives on the same day.
Test delivery the way a customer would meet it. Request a confirmation and a password reset for addresses on several email services, including a work address if you can borrow one. Note how long each takes and which folder it lands in. Then open the sign-in service's own log, where it has one, and see whether it recorded the messages as sent. A message the service never sent points to a limit or a setting. A message it sent that never appeared points to delivery.
The lasting fix is commonly to send these emails through an email service connected to your own domain, and to add the domain records that service asks for so inbox providers can verify the sender. That is a setup task, and the email service will give you the steps. Afterwards, repeat the same test and keep the results.
Links and sign-in buttons that still point at the building environment
After a person clicks a confirmation link, or finishes signing in with an outside provider, they are sent back to an address your app registered in advance. While the app was being built, that address was a preview or localhost, which is an address that exists only on the builder's own computer. If nobody changed it at launch, the email link sends your customer to a page that will not open for them.
There are usually two places to look. The sign-in service has a setting for the site's address and a list of addresses it is allowed to send people back to. Each outside provider, such as Google, keeps its own list of allowed return addresses as well. Your real domain has to be in both, spelled the way the browser shows it, including whether it starts with www.
Some providers also keep a new connection in a testing state, where only accounts you named in advance may sign in. That explains a button that works for you and your co-founder and refuses a stranger. The provider's console shows which state the connection is in and what it asks for before opening it to everyone, which can include a review.
A reset link that led nowhere
Signed in, then signed out again
Once a person signs in, the app keeps a small record in their browser that says who they are, called a session. Sessions are meant to expire and be renewed quietly in the background. When the renewal step is missing or failing, the user is thrown back to the sign-in page after a refresh, after an hour or the next morning, and to them it looks as if the app forgot who they were.
Reproduce it with a clock. Sign in on the live site and note the time. Refresh the page. Open the app in a second tab. Close the browser, reopen it and come back. Leave it overnight and try again. Write down which of these signed you out. Repeat the test on a phone, since mobile browsers are often stricter about what a site may store.
In the apps we see, the usual causes are a page that looks for the session before it has loaded and sends the user away too early, a live site reachable at two addresses so that a session saved under one is missing under the other, and renewal code that was never written. The pattern you recorded tells an engineer, or the tool you built with, which of these to look at first.
Signed in and looking at an empty account
Signing in proves who someone is. What they may read and change is decided by a separate set of access rules on the stored data, and those rules are often left half done because the app seemed to work for its builder. When the rules are too strict, or were never written for a table, a real user signs in successfully and every list comes back empty. To the user that is a login failure, and they will report it as one.
Check it with a fresh account on the live site. Create something, such as a project or a booking, and confirm it appears. Sign out, sign back in and look again. If the record has gone or never showed, the rule for reading your own records needs attention. Then sign in as a second new account and confirm that it cannot see what the first one made. Be careful with a quick fix here: loosening the rules until the account fills up can leave every customer's records readable by every other customer.
What you can fix yourself and when to ask for help
Site addresses, allowed return addresses and the email sender are settings. With the test results from this page you can usually correct them yourself, or have your builder do it, and then rerun the full journey in a new account. Keep a note of each setting you changed and the value it had before.
Ask for help when the fault is in sessions or access rules, when a fix for one account breaks another, or when real customers are locked out and you cannot reproduce what they see. Those faults sit in code and database rules, where a wrong guess can expose data. When you ask anyone for help, us included, describe the failing step and share access through each service's invitation feature. Never put a password, a secret key or a reset link into a contact form or a chat. Our Diagnostic is a fixed-price written plan that covers what blocks launch and what to fix first, credited to the build if you go ahead, and your repo and accounts stay yours throughout.
Before you change any sign-in setting
Record these first, so you can tell whether a change helped and undo it if it did not.
- The step that fails, the exact message, and the email service of the account that hit it.
- Where each test email landed and how long it took, for at least two email services.
- The full address inside a confirmation link and inside a reset link.
- The site address and the allowed return addresses in the sign-in settings, as they are now.
- For each outside sign-in provider, whether it is open to everyone or still in testing.
- Whether a new account still sees a record it created after signing out and back in.
We can get your users signed in.
Book a free consultation and tell us which step fails and for whom. If it is a setting, we will say so and you can change it yourself. If we take the work on, we fix sign-in in your own accounts, test every step with new users on several email services, and give you the notes.
Book a free consultationOn the project call, we’ll discuss the problem, your existing tools and what TDAT should take off your hands. Then we can define the scope and next steps.
Or call (919) 289-1231
Questions before we start
Why does login work for me and fail for my users?
Your account was usually created while building, on the preview, with an email address the settings already allow. A new user goes through confirmation emails, return addresses and access rules that your account skipped. Test with a brand new address in a private window to see what they see.
Why are my confirmation emails going to spam or not arriving?
Commonly because they are sent by the sign-in service's default sender, which is meant for testing, or because your domain has no records telling inbox providers the mail is genuine. Sending through an email service connected to your own domain usually deals with both.
The link in my email goes to localhost. How do I fix it?
The site address in your sign-in settings still holds the address used during building. Change it to your live domain and add that domain to the allowed return addresses. Then request a new email, because links in emails already sent keep the old address.
Why does Google sign-in only work for my own account?
The connection with the provider is often still in a testing state that admits only accounts you listed, or its allowed return addresses do not include your live domain. The provider's console shows the current state and what is needed to open it up.
Can TDAT fix login without rebuilding my app?
Often, yes. Login faults are usually settings, a missing step or unfinished access rules, and the screens stay as they are. On a free consultation we will tell you if it sounds like a settings change you can make yourself.