# Debug sign-in problems

> A user cannot get into your app. Match the exact refusal message, run the five-minute diagnosis, and fix the real cause.

Sign-in problems are stressful because they block real people, often your customers, at the front door. The good news: nearly every case lands in one of the buckets below, each with a specific fix. Start with the refusal message if there is one; it is the fastest route to the right bucket.

## Read the message first

The portal shows a specific sentence for every deliberate refusal. Match it here:

| The user sees | What it means | The fix |
| --- | --- | --- |
| "You do not have access to this app yet. Ask whoever runs it to send you an invite, then sign in again." | Your app is set to "Only people on your list" and their email is not on it | Add them in **Vault → Auth → App Users**, or switch registration to open |
| "Your access to this app is not active." | Their account was suspended or removed | Reinstate them in App Users |
| "This app has reached its member limit." | You are at your plan's user cap (20 on Free) | Remove unused accounts or upgrade |
| "Your sign-in link or code has expired. Request a new one." | The code sat too long, or an older email was used | Request a fresh code and use the newest email |
| "Sign-in was opened from an address this app does not recognise." | The portal was opened from an unexpected origin | Have them open your app at its real address and sign in from there |
| "This app could not be found. It may have been unpublished." | The app the portal was asked about does not resolve | Check your app is published and its address is correct |
| "This app requires sign-in, but sign-in is temporarily unavailable." | A temporary platform-side condition on a walled app | Wait a moment and retry; contact support with your project ID if it persists |

Everything else on this page covers the cases that fail without a clear message.

## The five-minute diagnosis

### Reproduce it yourself, signed out

Open your published app in a private browser window and walk the exact flow the user described. Most reports become obvious in the first minute: a popup blocker, a wrong address, an invite that was never sent.

### Check the Auth panel state

In **Vault → Auth**, confirm three things: the providers you expect are enabled, the registration setting matches your intent ("Anyone can sign in" vs "Only people on your list"), and the user in question appears in App Users in the state you expect (invited, active, not suspended).

### Separate settings from code

Provider and access changes apply to the live app immediately. But the sign-in **pages and buttons in your app are code**, and code waits for a publish. If you enabled a provider and the button is missing, or you built a login page and the live app lacks it, publish and re-test.

### Check the browser, not just the app

The portal opens in a small window; an aggressive popup blocker can eat it silently, which looks like "the button does nothing". Try once with popups allowed. Extensions that block third-party frames or storage can also interfere; a clean private window is the honest test.

### Test the full round trip with a throwaway account

Sign up with an address you control, complete the code step, confirm you land back signed in, and confirm the account appears in App Users. If this works for you and still fails for the user, the difference is in their environment or their account state, and the buckets below narrow it.

## The common buckets

### The sign-in email never arrives

Have the user check spam and promotions. Codes expire quickly and each new request replaces the last, so the newest email is the only valid one. If your app is invite-only, an uninvited address is refused before any email is sent; check the list first. If mail is broadly not arriving for anyone, contact support.

### "The button does nothing"

Popup blocker, almost always. The portal opens in its own small window and blocked popups fail silently in some browsers. The second suspect: the user is clicking a sign-in button on a page that was published before you finished configuring auth; republish and re-test.

### The user signs in but is bounced straight out again

Their account state is refusing them after authentication: suspended, removed from the invite list, or over the member cap. The table at the top maps each refusal. Note one subtlety: someone who is already a member keeps access even if their invite row was later revoked; to actually remove a member, suspend or delete the account in App Users, not just the invite.

### Signed in, but the app shows no data

That is not a sign-in problem; sign-in worked. It is a [data privacy](/docs/data/data-privacy) question: the rows they expect are private to another user, or the table's class is stricter than you intended. Test with two accounts and tell the agent who should see what.

### The user says "I already have an account" on their first visit

Expected. End users have one identity across apps built on Vaulter, so someone who used another Vaulter-built app with the same email signs in rather than signs up. Access is still strictly per app: knowing the account does not grant your app anything until they sign in to yours and pass your registration rules.

### A walled app loops or shows only the sign-in screen

With "Require sign-in to view" on, the app serves nothing until sign-in completes; strangers seeing only the portal is the feature working. A genuine redirect loop (portal, app, portal again) that persists is worth reporting; note the exact address and time and contact support with your project ID.

### Google, Microsoft, or GitHub sign-in fails midway

The provider's own window opens and errors, or closes without completing. Have the user retry in a normal (non-incognito) window first; third-party sign-in inside private windows with strict tracker blocking is flaky in some browsers. If one provider consistently fails while email codes work, disable and re-enable that provider in the Auth panel, then re-test.

### Publish is blocked with an auth message

The publish check found a sign-in surface in your app without the account system ready behind it, and stopped a decorative login page from shipping. It normally reconciles automatically; if the publish still fails, the message names the problem, and asking the agent to fix exactly that is the path. See [the sign-in portal's safety net](/docs/auth/sign-in-portal).

## When you report it to support

Include the user's email address (so we can find the attempt), the exact refusal text or a screenshot, the time it happened, and your project ID. One reproducible example is worth ten descriptions.