Slack Notifications for SaaS via Webhooks | Coding Capybaras

Photo by Ethan Wilkinson on Unsplash

The fastest way to send your SaaS events to Slack is an incoming webhook: you create a small Slack app, flip on incoming webhooks, and Slack hands you a secret URL. Any time something happens in your app worth knowing about — a new signup, a payment, a server error — your code sends a short JSON payload to that URL and the message appears in a channel. No polling, no Slack SDK, no OAuth dance. For a solo founder, this is the cheapest early-warning system you can build: the first time a stranger pays you, a message lands in #sales and you feel it in real time. This guide walks the full setup, a reusable helper for Next.js, and — just as important — what not to alert on so the channel stays useful.

TL;DR

• Incoming webhooks post messages into Slack via a unique URL you POST a JSON payload to. No SDK required.
• Setup is four steps: create a Slack app, enable incoming webhooks, add a webhook to a channel, test with curl.
• Store the webhook URL in .env.local — it's a secret, and Slack revokes leaked ones automatically.
• Wrap the send in one helper (sendSlack) and call it from your event points; never scatter fetch calls across the codebase.
• Alert on the handful of events you'd want to hear about at dinner. Everything else is noise that trains you to ignore the channel.

How do Slack incoming webhooks work?

An incoming webhook is a unique URL that turns an HTTP request into a Slack message. Slack generates the URL for you; you send it a JSON body; Slack posts the contents to a specific channel. That's the entire model. The official Slack documentation describes it as "a way to post messages from apps into Slack," and the simplest possible message is one line:

POST https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX
Content-type: application/json

{ "text": "Hello, world." }

Send that, and "Hello, world." appears in the channel you attached the webhook to. There's no library to install and no authentication header — the secret is baked into the URL itself, which is why guarding that URL matters so much.

A few constraints are worth knowing before you build. A webhook is tied to one channel, chosen when you create it; you can't redirect it at send time. You also can't override the app's username or icon per message, and — importantly — you cannot delete or edit a message once a webhook posts it. If you need to update messages, delete them, or route dynamically, you've outgrown webhooks and want Slack's chat.postMessage API instead. For notifications, none of these limits matter; a fired alert is a historical fact you want to keep anyway.

Webhooks are also rate-limited to roughly one message per second per URL, with short bursts tolerated. That's plenty for event notifications and a useful natural cap — if you're bumping that limit, you're almost certainly over-alerting, which the fatigue section below is all about.

Setting up an incoming webhook, step by step

The setup lives entirely in Slack's UI and takes a few minutes. You don't write any code to generate the webhook — only to use it.

1. Create a Slack app. Go to api.slack.com/apps, click Create New App, choose "From scratch," give it a name (My SaaS Alerts is fine), and pick the workspace to install it into. If you expect a lot of test messages while you build, make a dedicated #sandbox channel first.

2. Enable incoming webhooks. On your new app's settings page, select Incoming Webhooks in the sidebar and toggle Activate Incoming Webhooks to on. The page refreshes and reveals more options.

3. Add a webhook to a channel. Click Add New Webhook to Workspace. Slack runs a short install flow and asks which channel this webhook should post to. Pick one — say #alerts — and authorize. (To post to a private channel, you have to be a member of it first.) You'll land back on the settings page with a new URL under Webhook URLs for Your Workspace that looks like https://hooks.slack.com/services/T…/B…/X….

4. Test it. From your terminal, fire a request at the URL to confirm it works:

curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"First alert from my SaaS 🎉"}' \
  https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX

Check the channel — the message should already be there. That's the whole integration proven end to end before you've touched your app's code. If you want richer messages later, the same URL accepts Block Kit layouts; more on that below.

Do not commit that URL to git. It's a live secret — anyone who has it can post to your channel — and per Slack's own warning, "Slack actively searches out and revokes leaked secrets." A URL pushed to a public repo will simply stop working. Store it in .env.local, the same discipline I apply to every key in the boilerplate.

Wiring it into your Next.js SaaS

The pattern that keeps this maintainable is one small helper that everything else calls. Don't scatter raw fetch calls to Slack across your codebase — you'll never be able to change the format or add a kill-switch later. In Coding Capybaras this lives as a product-specific lib at /product/lib/slack/notify.ts:

// /product/lib/slack/notify.ts
const WEBHOOK_URL = process.env.SLACK_WEBHOOK_URL;

export async function sendSlack(text: string) {
  if (!WEBHOOK_URL) return; // no-op in local/dev if unset

  try {
    await fetch(WEBHOOK_URL, {
      method: "POST",
      headers: { "Content-type": "application/json" },
      body: JSON.stringify({ text }),
    });
  } catch (err) {
    // Never let a failed notification break the actual request
    console.error("Slack notify failed:", err);
  }
}

Two design choices there are deliberate. The helper no-ops when the URL is unset, so your local environment stays quiet without special-casing. And it swallows its own errors — a Slack outage or a typo in the URL should never take down the signup or payment flow it's attached to. A notification is a nice-to-have; the underlying request is not. This is the same "notifications are best-effort" principle behind treating them as fire-and-forget rather than part of the critical path.

Now call it from your event points. The natural place is right after the event is confirmed — a completed Stripe webhook, a finished signup:

// after a successful checkout, inside your verified Stripe webhook handler
await sendSlack(`💰 New payment: ${email} — $${(amountCents / 100).toFixed(2)}`);

Attach it to a verified event, not a raw incoming request. For payments that means inside your signature-verified Stripe webhook handler — the same handler whose gotchas I catalogued in Stripe webhook hell. Firing a Slack alert on an unverified request means anyone who finds your endpoint can spam your channel with fake "payment" messages. Verify first, notify second.

Here's the flow end to end:

flowchart LR
  A[App event<br/>signup / payment / error] --> B[sendSlack helper<br/>/product/lib/slack/notify.ts]
  B --> C[POST JSON to<br/>hooks.slack.com URL]
  C --> D[Message posts to<br/>#alerts channel]
  B -. on failure .-> E[console.error<br/>request continues]

For events that aren't tied to a web request — a nightly digest, a "trial expiring tomorrow" nudge — call the same helper from a scheduled job. That's exactly the kind of work background jobs exist for, which I covered in Inngest for background jobs in indie SaaS apps.

One more piece of hygiene: use different webhook URLs for local and production. The last thing you want is your dev environment firing "New payment" messages into the same channel your real sales land in, or a test loop spamming the team. Create a second Slack app (or a second webhook pointed at #sandbox) and set SLACK_WEBHOOK_URL to that value in .env.local, while production uses the real one in your host's environment variables. Because the helper reads the URL from the environment, the same code sends to the right place with no branching — dev noise stays in the sandbox, real alerts stay clean.

A note on timeouts. The fetch above will wait for Slack to respond, and on a serverless platform a slow Slack request eats into your function's execution budget. For notifications on a hot path — inside a request the user is waiting on — you have two options: fire the send without awaiting it (accepting that a failure is silently dropped), or move the notification into a background job so the user's request returns immediately. For most early-stage alerts the plain await is fine; Slack is fast and the volume is low. Reach for the background-job version once you're sending enough notifications that the added latency shows up in your response times.

What's actually worth alerting on?

This is where most Slack integrations quietly fail. It's tempting to alert on everything — every page view, every API call, every login. Do that and within a week the channel is a firehose nobody reads, which is worse than no channel at all, because now you're trained to ignore it. The one alert that mattered scrolls past unseen.

The filter I use: would I want to hear about this at dinner? If yes, it's an alert. If no, it belongs in your analytics or your logs, not in a channel that's supposed to make you look up.

| Event | Alert to Slack? | Why | | --- | --- | --- | | New paying customer | Yes | Rare, motivating, and you may want to act (say thanks, watch onboarding) | | Failed payment / dunning | Yes | Revenue at risk; a personal nudge can recover it | | Cancellation | Yes | Rare and worth a personal follow-up while it's fresh | | Unhandled server error | Yes | You need to know before customers tell you | | New signup (free) | Maybe | Motivating early; turn it off once volume climbs | | Support message received | Yes | Response time is your reputation as a solo founder | | Every page view / login | No | Pure noise — this is what analytics is for | | Every successful API call | No | Volume drowns everything that matters |

Note the "Maybe" row. New-signup alerts are wonderful when you have three a week and demoralizing-to-mute when you have three hundred a day. Build the alert so it's easy to switch off per event type, and expect the right set to shrink as you grow. Volume metrics belong on a dashboard you check on purpose, not in a channel that interrupts you — I laid out what to actually measure in the first-month SaaS dashboard.

One more discipline: route different severities to different channels. Errors to #alerts, sales to #revenue, support to #support. Because each webhook is bound to one channel, this just means creating a separate webhook per channel and picking the right one in your helper. It keeps the celebratory messages and the "something's on fire" messages from blurring together.

Making messages readable with Block Kit

Plain text is fine to start, but once alerts pile up you'll want them scannable. Slack's Block Kit lets you send structured layouts — headers, fields, dividers — instead of one run-on line. The webhook accepts a blocks array alongside (or instead of) text:

await fetch(WEBHOOK_URL, {
  method: "POST",
  headers: { "Content-type": "application/json" },
  body: JSON.stringify({
    text: "New payment received", // fallback for notifications
    blocks: [
      { type: "header", text: { type: "plain_text", text: "💰 New payment" } },
      {
        type: "section",
        fields: [
          { type: "mrkdwn", text: `*Customer:*\n${email}` },
          { type: "mrkdwn", text: `*Amount:*\n$${(amountCents / 100).toFixed(2)}` },
        ],
      },
    ],
  }),
});

Always keep the top-level text field as a fallback — it's what shows in the mobile push notification and notification preview, so a message with only blocks and no text arrives as a blank buzz on your phone. Beyond that, resist the urge to over-design. An alert's job is to be read in half a second while you're doing something else; a header and two fields beats a beautifully formatted card you have to study. You can preview layouts in Slack's Block Kit Builder before shipping them.

If your alerts start needing buttons — "approve," "refund," "reply" — that's the signal you've outgrown incoming webhooks and want a full Slack app with interactivity. For notifications, though, one-way messages are the whole job, and Block Kit's static layouts cover it comfortably.

Frequently asked questions

Do I need to build a full Slack app to send notifications?

You create a minimal Slack app to generate the webhook, but you don't write or host any app code. Once you have the webhook URL, sending a notification is a single HTTP POST from your existing backend. It's the lightest possible integration Slack offers.

Where should I store the Slack webhook URL?

In .env.local (and your host's environment variables in production), never in your source code. The URL is a secret that lets anyone post to your channel, and Slack automatically revokes URLs it finds leaked in public repositories. Treat it exactly like an API key.

Can one webhook post to multiple channels?

No. Each incoming webhook is bound to a single channel chosen at creation. To post to several channels — errors to one, sales to another — create a separate webhook per channel and select the right URL in your notification helper. This is a feature, not a limitation: it keeps different alert types cleanly separated.

Will a Slack outage break my app?

Only if you let it. Wrap the send in a try/catch that logs and moves on, as in the helper above, so a failed or slow Slack request never blocks the signup or payment it's attached to. Notifications should always be best-effort and off the critical path.

How do I avoid Slack notification fatigue?

Alert only on events you'd genuinely want interrupted for — payments, cancellations, errors, support messages — and send high-volume data (page views, logins, API calls) to analytics or logs instead. Make each alert type easy to switch off, and expect the useful set to shrink as your volume grows. A channel you actually read beats a complete one you've learned to ignore.

Can I send errors to Slack instead of using an error tracker?

You can, but they solve different problems. Slack is great for a real-time heads-up that something broke; a dedicated tracker groups errors, keeps stack traces, and shows trends over time. Most founders use both — an alert in Slack, full detail in the tracker. See adding Sentry to a Next.js SaaS for the tracker side.

The bottom line

Slack notifications are one of the highest-return, lowest-effort things you can wire into an early SaaS: a few minutes of setup, one small helper, and suddenly your product's most important moments reach you the instant they happen. The trick isn't the plumbing — it's the discipline. Send events through a single helper, keep the webhook URL out of git, verify before you notify, and alert only on what you'd want to hear about at dinner. Get that restraint right and the channel stays a signal instead of decaying into noise.

If you're building on Next.js, Supabase, and Stripe and want the event points already mapped out, the Coding Capybaras marketplace has copy-paste AI prompts that wire integrations like this straight into your app — paste one into Claude Code or Cursor and you have the working helper in minutes.