How to fix unexpected_failure: Unexpected service failure in Supabase

Open the Supabase Dashboard, navigate to Auth → Logs (or Monitoring → Logs), and set the time range to capture the error:

1. In the Supabase console, go to Logs or Log Explorer
2. Set the time range to include when the error occurred
3. Search for entries related to the failed auth operation (signUp, signIn, resetPassword, etc.)
4. Look for underlying database errors such as:
- "permission denied for table X"
- "violates foreign key constraint"
- "function "X" does not exist"
- "relation "X" does not exist"

These logs contain the actual database error that triggered the "unexpected_failure" response.

In the Supabase Dashboard, navigate to Database → Triggers and review any custom triggers on the auth schema or tables that interact with auth.users:

SELECT event_object_table, trigger_name, action_statement
FROM information_schema.triggers
WHERE trigger_schema = 'auth'
ORDER BY event_object_table;

Common trigger issues:
- Trigger function references a table that does not exist
- Trigger tries to insert into a table without the supabase_auth_admin role having permission
- Trigger has uncaught error handling

For each problematic trigger:

-- Temporarily disable the trigger to confirm it's the cause
ALTER TABLE <table_name> DISABLE TRIGGER <trigger_name>;

-- Test the auth operation (signUp, signIn, etc.)

-- If it works, the trigger is the issue. Recreate it with SECURITY DEFINER:
CREATE OR REPLACE FUNCTION trigger_function_name()
RETURNS TRIGGER
SECURITY DEFINER
SET search_path = public
AS $$
BEGIN
  -- Your function logic here
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

The SECURITY DEFINER clause ensures the function runs with the privileges of the user who created it (usually postgres), not the calling role.

If logs show "violates foreign key constraint", you likely have a foreign key between auth.users and a custom table:

SELECT constraint_name, table_name, column_name
FROM information_schema.key_column_usage
WHERE table_name = 'users' AND table_schema = 'auth';

The issue arises when:
- A user tries to delete their profile but a foreign key prevents it
- Supabase tries to clean up user data and the custom table blocks it

To fix, either:

1. Use CASCADE DELETE (automatic cleanup):

ALTER TABLE public.profiles
DROP CONSTRAINT <fk_constraint_name>;

ALTER TABLE public.profiles
ADD CONSTRAINT <fk_constraint_name>
FOREIGN KEY (user_id)
REFERENCES auth.users(id) ON DELETE CASCADE;

2. Use SET NULL (soft delete):

ALTER TABLE public.profiles
DROP CONSTRAINT <fk_constraint_name>;

ALTER TABLE public.profiles
ADD CONSTRAINT <fk_constraint_name>
FOREIGN KEY (user_id)
REFERENCES auth.users(id) ON DELETE SET NULL;

Choose CASCADE if users should be completely removed, or SET NULL if you want to keep the profile record but orphan it.

The supabase_auth_admin role (used by Auth internally) has limited permissions by design. If your trigger or function tries to access a table outside the auth schema, it will fail:

-- Check what supabase_auth_admin can access
SELECT grantee, privilege_type, table_name
FROM information_schema.role_table_grants
WHERE grantee = 'supabase_auth_admin'
ORDER BY table_name;

If the auth role lacks permission to a table your trigger needs:

-- Grant SELECT, INSERT, UPDATE, DELETE on public.profiles to auth admin
GRANT SELECT, INSERT, UPDATE, DELETE ON public.profiles TO supabase_auth_admin;

-- Or use a SECURITY DEFINER function (postgres runs it with full privileges)
CREATE OR REPLACE FUNCTION my_trigger_function()
RETURNS TRIGGER
SECURITY DEFINER
AS $$
BEGIN
  -- This runs as postgres, so it has access to all tables
  UPDATE public.profiles SET updated_at = now() WHERE user_id = NEW.id;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Prefer SECURITY DEFINER for auth-related triggers so they always have the necessary permissions.

Invalid email templates can also cause "unexpected_failure" errors during password resets or magic link flows.

In the Supabase Dashboard:
1. Go to Auth → Email Templates
2. Review each template for:
- Unclosed HTML tags (e.g., missing </a>, </div>)
- Invalid variable syntax (should be {{ variable }}, not {variable})
- Forbidden characters (single quotes, unescaped backslashes)

Test a simplified template first:

<h1>Confirm your email</h1>
<p><a href="{{ .ConfirmationURL }}">Confirm Email</a></p>

If the simplified version works, gradually add back template logic and test each change.

If logs don't show database errors and triggers/templates are correct, the issue may be resource exhaustion:

1. In the Supabase Dashboard, go to Database → Monitoring or Project Settings → Compute
2. Check for:
- High connection count (approaching the connection pool limit)
- CPU or memory usage spikes during auth operations
- "too many connections" errors in the database logs

If you see resource constraints, upgrade:
- Connection pooler settings: Increase pool size in Project Settings → Database → Connection Pooling
- Compute add-on: Add more RAM/CPU to your project from Billing → Compute

Restart the Auth service after resource upgrades to clear any stuck connections.