Symptom guide / Accounts and private data
Login that stops working
Login rejects a known test account, loops back to the form, or returns you to the wrong address.
Use an account you created for testing, with a password you can enter yourself. Write down whether the failure happens before leaving the form, on the identity provider’s page, or after coming back. Those are different points in the journey. Changing all authentication settings at once makes it harder to learn which point was broken.
01 / Procedure
The two-minute check.
- Check the form before changing the backend.
Open the published login page. Submit the test account once and read any message next to the fields. Confirm the email and password fields are filled. Note whether the page stays still or starts navigating.
- Follow the request.
Right-click, choose Inspect, open Network and enable Preserve log. Repeat the login once. Select the authentication request and read its status and Response. Keep the message, but do not copy the password, authorization header or session token.
- Read the return address.
If the login opens another site, follow it back and compare the final address with your production domain. For Supabase, open Authentication, URL Configuration in the project dashboard and compare Site URL and allowed redirect URLs with the destination your app requests.
- Test a fresh session.
Try the same test login in an incognito window. After it succeeds, open one page that requires login and reload it. Record whether only the old browser session fails or whether both sessions lose access.
02 / Evidence
Read the result.
WORKSThe test account returns to the live app and still reaches its private page after reload.
BROKENThe same account fails at a repeatable stage or arrives at the wrong destination.
03 / Repair
Causes and fixes.
Ranked in the order to investigate, not by claimed frequency.
- The form rejects input before authentication.
Show a specific field-level validation message and correct the submitted values. Confirm an empty field cannot produce a misleading success screen. Do not reset the database to repair a form message.
- The provider rejects the requested return URL.
Set the production return address in the provider’s allowed redirects and make the app request that address. For Supabase, use the exact production path; reserve broad preview patterns for the preview environments that need them.
- The authenticated session is not used for the next request.
Compare the successful login with the failed private-page request. Repair session handling at that boundary instead of opening the private route to everyone.
04 / Limits
Edge cases.
- An account existing in a development project does not establish that it exists in the production project. Compare the project receiving the login request.
- Email confirmation, recovery links and social login are separate journeys. A password login passing does not establish that those other journeys work.
When to stop and hand it over
Hand it over when the provider accepts the login but the app repeatedly loses the session, or when you cannot identify which auth project is live. Supply the failing stage, return URL and redacted response, never a real user’s password.
05 / Questions
Before the next attempt.
Can I turn off authentication to test?
That would change the journey you are investigating. Keep private pages protected and use a disposable account.
Is every login failure a backend outage?
No. The Tiniary case below shows a field validation problem that looked like a server failure.