New customer signup notification: how to get notified when someone signs up

How to get notified of a new signup: the short answer

To get a new customer signup notification, route a webhook from whatever creates the account — your auth provider or Stripe's customer-created event — into a channel you watch, or wire the same event into Slack with Zapier or Make. That is the free, same-afternoon answer. If you would rather not build anything, a dedicated signup-notification tool such as Saastoast pushes new-customer events straight to Slack or Telegram, and most product-analytics tools can raise a "new user" alert on account creation. Each of these is a good option, and for the plain question — did someone just sign up? — any of them answers it.

So this guide does two things. First, it sets each option up properly, because a "get notified of new signups" search deserves real setup steps, not a pitch. If you never read past the Zapier section, you will still leave with working notifications. Second, once the free and paid options are on the table, it is honest about the one thing they all stop short of. Every method below is triggered by a single account-created event, which means every one of them can only tell you about that event. The moment you want the alert to answer the next, more useful question — who was that, where did they come from, and are they the kind of customer worth reaching out to today? — you have left what a signup-triggered ping can do. That gap, and how an identity-joined new-customer alert closes it, is the back half of the article.

The building block: a signup webhook

Nearly every signup notification, however fancy, starts from the same primitive: a webhook fired when an account is created. It is worth understanding this layer directly, because it is free and it is what the paid tools are quietly built on.

1. Find the event that means "new customer." Depending on your stack, that is a new-user event from your auth provider, a customer.created event from Stripe, or a row inserted into your users table. Pick the one that best matches your definition of a real signup.
2. Point it at a receiver. Send the webhook to an endpoint you control, or straight to an incoming webhook URL for Slack or another channel. The payload usually carries an email, an ID, and a timestamp.
3. Format a readable message. Turn the raw payload into a line a human can read — "New signup: [email protected]" — and post it where you will see it.

What you get is immediate and free: the instant an account exists, you know. What you do not get is anything about the person beyond the identifier in the payload. The webhook is scoped to the account-created event, so it reports the fact of the signup and stops. That is not a flaw — it is what a signup event is. It just means the notification answers "someone joined" and leaves "who, from where, on what plan, worth watching or not" for you to go assemble by hand.

Slack, email, and SMS via Zapier or Make

Wiring webhooks by hand is fine, but most teams want new signups to land where they already talk without writing code. The standard route is Zapier or Make, and it is quick.

1. Create an automation with a new-user trigger. Choose a trigger like a new row in your database, a new user in your auth tool, or a new Stripe customer, and connect the account.
2. Pick your channel as the action. Add a Slack "Send Channel Message" action, an email action, or an SMS action. Map the email and any fields you like into the body — for example, "New signup: {{email}} at {{created}}."
3. Test and turn it on. Create a test account, confirm the message posts, and switch it live. From then on, every new signup posts to your channel within a minute or two.

This is a good pattern and worth setting up — a channel that lights up on every signup is a nice heartbeat for a small team. Just be clear-eyed about what travels through it. The message can only contain what the trigger event contains, because that is what fired it. You can format the email nicely and add an emoji, but the automation cannot enrich the alert with where the person came from or which plan they chose, because that context is not in the account-created event — it lives in your analytics and your entitlements, which the signup trigger never touches. You will get a tidy "New signup: [email protected]" in Slack. You will not get "New signup — Priya, Pro trial, came in from a comparison-page read, already fired her first events."

Dedicated signup-alert tools

If you would rather not maintain a Zap, there are purpose-built tools that do this job out of the box. Saastoast is a well-known example: connect your Stripe account and it pushes new-customer and revenue events to Slack or Telegram, with a friendly message for each new signup. Tools like it are genuinely convenient — no automation to babysit, a clean message, and a channel that celebrates each new customer with you. If what you want is a tidy, reliable "someone just signed up" in a place your team watches, a dedicated signup notification tool does exactly that, with more polish than a raw webhook.

These tools are a step up from a hand-rolled webhook in presentation and convenience. What they share with every other option on this page is the source they read from. They are built on the signup or payment event, so the alert they raise is still, at heart, a signup ping: an email, a plan name if the processor supplies one, a timestamp. That is the right design for a lightweight new-customer notifier, and it is not a criticism of the tools. It is simply the boundary of the layer they work in. To cross it — to have the alert itself say where the customer came from and whether they resemble your best customers — the alert has to be built on something the signup event does not contain: the person's identity, joined to everything else you already know about them.

A "new user" alert from product analytics

There is a fourth route worth naming, because a lot of teams already have it: product-analytics platforms can raise a new user alert when an account-created event lands. If you are already tracking signups as events, you can often set a threshold or a per-event notification and route it to Slack or email. For a SaaS that lives in its analytics tool, this keeps signups in the same place as the rest of the funnel.

This is a reasonable option, and it has one advantage over a raw payment webhook: because it sits on your event stream, it can sometimes carry a little behavioural context — the page the signup happened on, say. But it inherits the same fundamental limit as the others, plus one of its own. The alert is still scoped to the signup event, so it reports that a user was created, not who that user turns out to be across your other systems. And in most stacks the analytics tool keeps its own identity for the user that is not joined to the customer record in your billing or entitlements — which is exactly the disconnect we wrote about in why your app analytics should connect to revenue events. A "new user" fired by analytics is a fine trigger; it is not, by itself, a new-customer alert, because it does not know what the customer is worth to the rest of your business.

Every method to get a signup notification, compared

Here is the honest comparison of the free and paid options above. Notice that the columns are all similar until the last one — because they are all reading the same single event.

The first four rows are the right answer to "how do I get notified of a new signup." If that is all you needed, you are done — pick one and set it up. The last row is a different kind of answer, because it is built on a different layer, and the rest of this guide is about why that last column matters the day a bare "new signup" stops being enough.

The wall: a signup ping tells you "new signup" and nothing else

Here is the moment every growing SaaS hits. A signup notification fires. It says new signup: [email protected]. And your very next thought is a run of questions the alert cannot answer: who is that? Where did they come from — a comparison-page read, a founder's tweet, a paid ad? Which plan did they start on — the free tier, or the Pro trial? Have they actually done anything yet, or is this a throwaway email that will never come back? Is this the kind of customer who tends to stick, or the kind who churns in a week? The signup ping is silent on all of it, and it is silent for a structural reason worth understanding.

A signup is a single-layer fact. An email, a timestamp, maybe a name. That is the entire content of the event, and so that is the entire content of any alert triggered by it — whether the alert lands in a webhook receiver, a Slack channel, or a dedicated tool. Everything you actually want to know about the new customer lives in other layers: where they came from lives in your analytics; which plan maps to the account lives in your entitlements; whether they have activated lives in your product telemetry; whether they resemble your best customers lives in the pattern across your revenue history. A single-source signup alert has no join to any of those layers, so it can report the account and only the account. It is not that the tools are underbuilt. It is that they are reading one event and the answer lives across several.

This is the same shape of problem behind a lot of "why can't my tools just tell me" frustration — signups in one place, customers in another, revenue in a third, and no thread connecting them. We have written about the broader version of it in the complete guide to app revenue intelligence, and about the closely related case of a sale alert that can't name the buyer in how to get a Stripe sale notification. The new-signup alert is where the gap shows up earliest, because the signup is the first time a person becomes a customer at all — and it is the exact moment you most want to know who just walked in.

An alert that names who signed up, where they came from, and their plan

The fix is not another notification channel. It is a different foundation under the alert. Crossdeck joins analytics, entitlements, revenue and errors by identity — the cross-match — so a new signup resolves to a person and lands on that person's one timeline. The account-created event stops being the whole story and becomes the first event on a real customer's history. And because that history is right there — including the reads that came before the signup — the alert can carry what the signup ping never could.

Concretely, instead of "new signup: [email protected]," an identity-joined new-customer alert reads more like: New customer — Priya. Started on the Pro trial. First-touch origin: a comparison-page read, not an ad. Already connected a project and fired her first events. Every one of those fields comes from a different layer, joined to one identity: the account from the signup, the plan from entitlements, the first-touch origin from analytics, the early activity from product telemetry. None of it is estimated or guessed — every field is read from your live Crossdeck data. (The name and details here are illustrative, but the shape of the alert is the real thing.) The origin field is deliberately a headline, not a lecture; if you want the full method behind capturing where customers come from, that is its own subject, covered in connecting your analytics to revenue events.

Notice what changes about the alert's job. A signup ping ends a thought — someone joined. An identity-joined new-customer alert starts one — this specific person just arrived, here is where they came from, and here is what they have already done. That is the difference between a notification you glance at and a notification you act on: you can send the high-intent trial a personal note, prioritise the signup that came from your best-converting origin, or notice that a promising new customer has already hit an error worth clearing before it sours the first day.

The last row is the whole argument. A signup ping is built on the account-created event, so it can only ever show you that event. An identity-joined alert is built on the customer, so the signup arrives with its context attached. Same trigger — a new account — but a different foundation, and therefore a completely different alert. You can see the customer side of it in the bot at any time with /people, which lists your latest customers and signups on demand, not only when an alert fires.

Ask a follow-up: "is this our best kind of customer?"

There is one more thing an identity-joined alert can do that a signup ping structurally cannot: hold a conversation. With a webhook, a Zap, or a dedicated tool, the message is the end of the exchange — if you want to know more, you go open a dashboard and start digging. Crossdeck delivers its new-customer alerts through a Telegram bot, live today in a private chat with you, and the chat is two-way.

When a signup lands, you can do more than read it. You can run /people to see your latest customers, open a Mini App dashboard for the fuller picture, or check /status for a health summary. And if you want to just ask, that is what Prism is for: with /prism you can type a plain-English question — "is this our best kind of customer?", "do signups from this origin usually convert to paid?", "how many new customers did we get this week?" — and get an answer off your live numbers.

Two things matter about how Prism works, and both are the point. First, it runs on your own connected AI model, with your own key — you connect a model in the Prism tab first, and from then on the questions are answered by your model, not by anything Crossdeck runs on your data. Crossdeck never trains on your data; the model and the key are yours. Second, the answer is grounded in your live Crossdeck data, so it is not a guess or a generic estimate — it is your real history, read at the moment you ask. You can see how that works on the Prism page. A new-customer alert you can interrogate is a different tool than one you can only read.

One honest note on scope: today the bot runs in your private chat, one-to-one. Shared team and group chats — where the whole team gets the new-customer alert and can ask Prism together — are on the roadmap, not shipped. So for now, think of it as your own line to your numbers, not a team channel yet.

How to choose

None of this means you should rip out what works. The right choice depends on what you want the signup alert to do, and for many teams the answer is more than one tool.

• If you just want to know a signup happened: a webhook into Slack, or a Zap, is free and enough. Set it up today.
• If you want new signups in your team's channel with no maintenance: a dedicated tool like Saastoast is a clean, reliable way to give a team a shared heartbeat.
• If you already live in your analytics: a "new user" alert there keeps signups next to the rest of the funnel.
• If you want the alert to answer the next question — who, from where, on what plan, worth reaching out to: you need an alert built on the customer's identity, not the signup event. That is the join Crossdeck makes, delivered to Telegram, with a follow-up you can ask.

The test is simple. Read your next signup notification and notice your very next thought. If it is "nice," a signup ping is doing its job. If it is "wait — who is that, and are they worth my time today?", that is the moment a signup ping runs out of road, and the moment an identity-joined new-customer alert earns its place. This post is part of a wider set on watching your business in real time — the hub is real-time business monitoring, and the closest neighbour is the same identity join pointed at a purchase rather than a signup, in how to get a Stripe sale notification that names the buyer.

If you want to see the alert with the customer attached rather than described, you can start free or look at how the cross-match works on cross-deck.com.

Frequently asked questions