How to get notified of every new Supabase signup

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

The cleanest way to get notified of every new Supabase signup is a Database Webhook on the auth.users table (or your own profiles table if you mirror it), configured to fire on INSERT and POST to Slack, email, or an endpoint you control. It requires no polling, no cron job, and no extra library — Supabase ships this natively in the dashboard under Database → Webhooks.

This post covers the actual setup, the gotchas that trip people up (RLS, service role keys, retries), and what to do with the notification once you have it — because "get pinged" is step one, not the goal.

Why polling is the wrong instinct

The first idea most people have is a scheduled function that runs every few minutes and checks SELECT * FROM auth.users WHERE created_at > last_check. It works, but it's the wrong tool: you're paying for compute to ask "anything new?" dozens of times a day when Postgres already knows the exact moment a row is inserted. Webhooks push the event to you the instant it happens, with zero polling overhead and zero risk of missing a row between checks.

Setting up the Database Webhook

1. In the Supabase dashboard, go to Database → Webhooks and create a new webhook.
2. Pick the users table under the auth schema (or your own public.profiles table if you sync it on signup — this is often cleaner since auth.users is locked down and you may not want webhook infra touching Supabase's internal schema directly).
3. Set the event to Insert only — you don't need Update or Delete for a signup alert.
4. Choose HTTP Request as the target, and point it at an endpoint. Options in order of setup effort:
   • Slack incoming webhook URL — fastest, gets you a message in a channel within minutes.
   • A serverless function (Supabase Edge Function, Vercel, Cloudflare Worker) — lets you enrich the payload, log it, or fan it out to multiple places (Slack + email + your own metrics store).
   • Zapier/Make webhook trigger — no-code, good if you want to route into email, a spreadsheet, or a CRM without writing anything.
5. Save. Supabase will POST a JSON payload with the new row's data (record) to your target on every insert.

A few things worth getting right the first time:

• Auth schema access: hooking into auth.users directly requires the webhook to have appropriate access — Supabase handles this internally when you create the webhook through the dashboard, but if you're doing it via SQL/migration, make sure you're using the supabase_functions schema conventions, not trying to attach a trigger without the extension enabled.
• Retries and failures: Supabase retries failed webhook deliveries a limited number of times. If your endpoint is down for an extended stretch, you can silently lose a notification. For anything you truly can't afford to miss, log deliveries somewhere durable (even a simple insert into a webhook_log table) rather than relying purely on Slack visibility.
• Payload contains PII: the new user's email and any custom fields on the row will be in the payload. If you're piping this into Slack or a third-party automation tool, that's raw personal data leaving your database — worth a beat of thought on where it ends up, especially if you're in the EU or handling regulated data.

What if you don't use Supabase Auth?

If you're managing your own users or customers table instead of auth.users — common if you migrated from another auth provider or run a custom signup flow — the same Database Webhook mechanism works on any table. Point it at whichever table receives the INSERT on signup completion. The setup is identical; only the table name changes.

Signup alerts vs. signup counts: two different problems

A webhook answers "did someone just sign up, right now." It doesn't answer "how does this week's signup count compare to last week's" or "which of my 6 apps is actually growing." Those are aggregation questions, and stacking them on top of a per-event alert system gets unwieldy fast — you end up building a mini analytics pipeline just to answer a trend question.

This is the line where a lot of solo founders start looking at something like Signals vs dashboards: which do you actually need? — a real-time ping is a signal, and it's genuinely the right tool for "notify me the moment X happens." A trend line over weeks needs a different shape of tool entirely.

Disclosure: SoleOS is built by the same team writing this post, and this section is, unsurprisingly, about SoleOS's own space — take the framing with that in mind.

SoleOS connects to Supabase as a signals source (alongside Firebase) specifically for this second category: not to replace your webhook, but to turn "signup happened" into "signup volume trend across all my apps this month," sitting next to Stripe and RevenueCat revenue in one place. If you only run one app and just want a Slack ping, the Database Webhook above is genuinely all you need — don't add a portfolio tool for a single signal on a single project. Where it starts to matter is once you have several apps and want to see signup trends alongside MRR without opening five dashboards. You can see the exact scopes involved at what SoleOS connects to, and how the read-only auth works at the security overview.

Turning a raw alert into something actionable

Once the notification is flowing, a few cheap upgrades make it more useful than a bare "new user" ping:

• Include the signup source if you track it (referral param, UTM, invite code) so the Slack message tells you where the user came from, not just that one arrived.
• Batch overnight signups into a single morning digest for high-volume apps — a webhook firing 40 times overnight is noise, not signal. A small Edge Function that queues and sends a daily summary solves this without losing the real-time option for your highest-priority app.
• Pair it with a churn or cancellation signal from Stripe so you're seeing the full picture — new users in, canceled subscriptions out — rather than only ever hearing good news. See tracking Stripe and RevenueCat together for how those two often need to be reconciled anyway.

Frequently asked questions

Does the webhook fire for OAuth and magic-link signups too?

Yes — any path that results in an INSERT into auth.users (email/password, OAuth providers, magic links) triggers the webhook the same way, since it's watching the table, not the auth method.

Can I filter the webhook to only fire for certain conditions, like verified emails?

The Database Webhook itself fires on any insert; if you need conditional logic (e.g., only alert once email_confirmed_at is set), route it through a small function that checks the payload and only forwards matching events, or trigger on the UPDATE event of that column instead of INSERT.

Is a Database Webhook the same as a Postgres trigger?

Under the hood, yes — Supabase's dashboard webhook feature creates a Postgres trigger and function for you. You can achieve the same result with a hand-written trigger and pg_net or http extension call, but the dashboard UI avoids the SQL boilerplate.

What's the delay between signup and notification?

It's effectively real-time — the trigger fires within the same transaction commit, and the HTTP call goes out immediately after. Any delay you see is almost always on the receiving end (Slack rate limits, cold-start on a serverless function), not on Supabase's side.

I run multiple apps on separate Supabase projects — do I need a webhook per project?

Yes, webhooks are configured per-project, so each app needs its own. If you want a single place to see signup activity across all of them without managing N separate Slack channels, that's the aggregation problem a portfolio-level signals view is built for — worth trying the live demo with sample data before deciding if it's worth wiring up for your case.