VVibeFix

Guide

"email rate limit exceeded" in Supabase and Lovable: which limit you hit and how to fix it

Sign-up, password reset or a magic link starts failing with "email rate limit exceeded". The raw response looks like {"code":"over_email_send_rate_limit","message":"email rate limit exceeded"} (Supabase GitHub issue #34136). It comes and goes: some people get in, others do not, and it clears if you wait.

Can a stranger actually sign up and get your email? Find out which of these is breaking your app, usually in 4 to 10 minutes.

Free. No account needed. It usually takes 4 to 10 minutes.

What the error means

Supabase returns 429 Too Many Requests when a rate limit is exceeded. Its error reference describes over_email_send_rate_limit as: "Too many emails have been sent to this email address. Ask the user to wait a while before trying again." A neighbouring code, over_request_rate_limit, means "Too many requests have been sent by this client (IP address)."

Several different limits can be behind it, counted per project, per person or per network address. The fix depends on which one fired. The numbers below are the documented defaults today; check the current pages before relying on them.

The causes, and how to fix each one

Start with the first one: it is the limit a project on the built-in email service meets first.

1. Supabase's built-in email service: 2 emails per hour for the whole project

Supabase documents "2 emails per hour with the built-in email provider", counted for the whole project. Two sign-ups in an hour use it up for everyone. This limit can only be changed by using your own SMTP or a Send Email hook.

How to fix it

  1. Choose an email provider (Supabase names Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail and Brevo as examples) and copy its SMTP host, port, username, password and sender address.
  2. In the Supabase dashboard, open the Authentication settings, enable custom SMTP and enter those values.
  3. Go on to cause 2, because custom SMTP starts with its own low limit.

Source: Supabase: Rate limits, Supabase: Send emails with custom SMTP

2. Your own SMTP: 30 messages per hour by default

Once custom SMTP is saved, Supabase imposes "a low rate-limit of 30 messages per hour". A launch, a post or a class signing up together can reach it. Your email provider can have its own quota as well.

How to fix it

  1. Open Authentication, then Rate Limits in the Supabase dashboard.
  2. Raise the email limit to what your expected sign-ups and resets need.
  3. Check your email provider's plan for its own hourly or daily sending cap.

Source: Supabase: Send emails with custom SMTP, Supabase: Rate limits

3. One person asked again within 60 seconds

Signup confirmation, password reset and one-time code or magic link requests default to "a 60 seconds window before a new request is allowed for the same user". A person who taps "resend" twice, or a screen that sends twice, hits it.

How to fix it

  1. Disable the resend or "send link" button for 60 seconds after each request, and say so on screen.
  2. Make sure the screen sends one request per tap (no double submit).
  3. If you need a different window, it is adjustable on the Rate Limits page.

Source: Supabase: Rate limits

4. Many requests from one network address

Sign-up, recovery, resend, magic link and one-time code requests are also counted per IP address: by default 30 requests per 5 minutes. Many people behind one office, school or mobile network count together. Supabase's error reference ties over_request_rate_limit to requests from one client (IP address).

How to fix it

  1. Open Authentication, then Rate Limits, and raise the sign-ups and sign-ins limit if real users share networks.
  2. Do not test with scripts that sign up dozens of addresses from one machine against your live project.

Source: Supabase: Rate limits

5. Lovable: the project limit or the workspace limit

On Lovable's built-in backend, each project has a "Rate limit for sending emails" setting for authentication emails per hour. On top of it, Lovable's Emails feature (paid plans) has hourly workspace limits: Pro 100 app emails and 500 authentication emails, Business 300 and 3,000, Enterprise 1,000 and 10,000. "When a workspace reaches a limit, Lovable rejects new emails until the hour resets."

How to fix it

  1. Open More, then Users, then Settings, then Email, and under Advanced check "Rate limit for sending emails".
  2. Before raising it, set up email sending first: Lovable's managed email or a verified custom domain.
  3. Watch More, then Emails: Lovable shows a warning once the workspace has used 80% of a limit.
  4. If the workspace limit itself is too low, Lovable says to contact Lovable Support.

Source: Lovable: Email authentication for your app, Lovable: Send branded emails from your own domain

Your AI reads your code. VibeFix signs up like a stranger. Find out which of these is breaking your app, usually in 4 to 10 minutes.

Free. No account needed. It usually takes 4 to 10 minutes.

Why you cannot see it yourself

You're signed in, your customers aren't. You test with one sign-up at a time, so you never get near an hourly cap. The limit is reached when real people arrive together, which is exactly the moment you are not watching.

Frequently asked questions

Why do I hit the limit after only a few test sign-ups?

This was asked in Supabase discussion #15880, where the answer was that the built-in sender is for basic testing only and you need your own SMTP. Supabase's current documentation gives the built-in limit as 2 emails per hour for the project.

Password reset says "email rate limit exceeded" but sign-ups still work. How?

One report, issue #34136, came from local development with the Supabase CLI, where raising email_sent in config.toml fixed it. On a hosted project, reset requests have their own 60-second window per user, and every auth email counts toward the project's hourly email limit. Wait 60 seconds between reset requests, and check the hourly limit on the Rate Limits page.

How can I test sign-up without burning the limit?

Supabase suggests an email testing tool such as Mailtrap while testing, and a real SMTP provider for production.

Does the person still get an account when the limit is hit?

The limit stops the email, so the person can be left waiting for a message that was never sent and later see "Email not confirmed". Once the limit resets, send them a new confirmation.

Related guides

Sources (official documentation)

Fixed it? Prove a real stranger gets in

After the fix, the proof is a new address getting its email on the first try, on your live app. Your own account cannot show that, because it is not new. Your AI reads your code. VibeFix signs up like a stranger.

Free check. An AI agent signs up to your live app as a brand-new person, with a real inbox of its own, on a phone and on a computer. You get the problem count, what each problem is, and one screenshot. It never changes your app and never emails your users. Test my app, free

$9 for one app. Shows which cause is breaking your app and where, the exact fix prompt for your app for every problem, plus 3 re-checks so you can see whether the fix holds for a stranger. It does not promise a fix; it shows what the agent saw.

VibeFix is independent. Supabase and Lovable are trademarks of their owners.

More guides