Supabase Auth providers show Enabled in Dashboard but runtime says disabled

[titutaweh-cmd]

Hello Supabase team/community,

I need help diagnosing a Supabase Auth issue with my production project.

I have already submitted a support request for this issue and am posting here to get community guidance while I wait for the support response.

Problem:

The Supabase Dashboard shows both Email and Google authentication providers as ENABLED, but the production Auth runtime behaves as though both providers are disabled.

Evidence:

1. Email/password sign-in

POST /auth/v1/token

HTTP 422

Error:
email_provider_disabled

Message:
"Email logins are disabled."

2. Password recovery

POST /auth/v1/recover

HTTP 400

Error:
email_provider_disabled

Message:
"Email logins are disabled."

3. Google OAuth

GET /auth/v1/authorize?provider=google

HTTP 400

Response:
"Unsupported provider: provider is not enabled"

However, in Supabase Dashboard:

Authentication → Sign In / Providers:

• Email: Enabled
• Google: Enabled

The detailed Email provider settings also show:
"Enable email provider" = ON.

The application is connected to the expected Supabase project.

A read-only investigation also found:

• Email authentication fails at the provider-availability stage, before password validation or user lookup.
• Google OAuth fails at provider availability.
• No Auth Hook is involved.
• This is not an RLS/database policy failure.
• The application code does not contain these backend error messages.
• Production and preview are connected to the expected Supabase project.
• The Auth log stream subsequently showed no Auth events for fresh sign-in/password-reset attempts, while other project logs were still active.

This appears to be a discrepancy between the provider configuration displayed by the Supabase Dashboard and the configuration being used by the Auth runtime.

Could someone please advise what could cause the Dashboard to show Email and Google as enabled while the Auth runtime reports both providers as disabled?

I have not changed Auth configuration, database schema, RLS policies, secrets, or application code while investigating this issue.

I will not post API keys, passwords, access tokens, database credentials, or other secrets here.

Thank you.

[DotDeon]

The detail that gives it away is the last one: fresh sign-in attempts produce no Auth events in this project's logs. GoTrue logs a 422 for a disabled provider just like any other failure. If the log stream is silent while other logs are active, those requests are not reaching this project's Auth at all. They're hitting a different one.

email_provider_disabled and Unsupported provider together are what a project with nothing configured returns, which fits that reading.

Check it from the runtime side, not the dashboard side. The anon key your production app is actually using is a JWT with a ref claim in it:

echo '<anon key>' | cut -d. -f2 | base64 -d 2>/dev/null; echo

Compare that ref with the project ref in your dashboard URL. Things that make them differ without anyone touching code: a hosting env var that was set at the project level and then overridden at the environment level, a preview branch key that got promoted, a custom domain or vanity subdomain still mapped to an old project, or a build that baked in the key at compile time and has not been rebuilt since the key changed.

If the ref genuinely matches, the fallback is a project restart under Settings → General, which forces the Auth service to reload its config. I'd only do that after the key check though, because in my experience it's almost always the key.

[titutaweh-cmd]

Thanks — I checked the runtime/project identity exactly as suggested, without exposing any keys.

The production build is confirmed to use the same Supabase project shown in the Dashboard:

Project ref: mbxbqvohiscdxzfizhok

The published site contains only:
mbxbqvohiscdxzfizhok.supabase.co

The production publishable key also matches the current project configuration. It is the newer sb_publishable_ format, so there is no JWT ref claim to decode.

No second/stale Supabase project or old JWT key was found.

Earlier Auth logs also showed the email_provider_disabled failures against this same project's Auth service.

So the wrong-project/stale-build theory appears ruled out.

The remaining discrepancy is that the Dashboard shows Email and Google enabled while the live Auth runtime rejects both as disabled.

I'm continuing with Supabase Support on the runtime configuration issue.