Automate Slack Notifications with n8n — 7 Practical Examples

The standard way teams handle deploy notifications is someone posts "deployed v2.4.1" to Slack manually — which means it happens inconsistently, without context, and often not at all when people are busy. What teams actually need from a deploy alert: which commits went out, who authored them, what the previous version was, and a direct link to the GitHub comparison so anyone can see exactly what changed.

The n8n workflow uses the GitHub Trigger node set to the push event, filtered to the main branch. The trigger payload includes the full commit list, each author, the before/after commit SHA, and the compare URL. A Set node extracts the last 3 commit messages (most pushes are 1–3 commits), formats them with author names, and the Slack node posts to #deployments using Block Kit — so the message has a header line with the branch name and time, a body with the commit list, and a button linking directly to the GitHub compare page.

The Block Kit formatting is worth the extra 5 minutes of setup. Plain text deploy messages in Slack get ignored. A message with a clear header ("main — 14:32"), commit list with author names, and a green "View changes" button gets clicked — which means the team actually knows what's running in production.

Lead notification is probably the most common Slack automation, and most implementations are bad — they send the name and email and nothing else. The reason the rep still has to open the CRM to understand the lead is that the automation didn't include the context: which page they came from, what they said in the message field, which UTM source brought them in. That context is what determines how to respond, and it's all available in the webhook payload.

The workflow uses a Webhook trigger node as the form's submission endpoint (or connects to Typeform/Webflow via their native n8n nodes). After the webhook receives the submission, an HTTP Request node immediately calls HubSpot's Contacts API to create the CRM record — so by the time the Slack message lands, the CRM record already exists and the message can link to it directly. The Slack node posts to #sales with the person's name, email, company (if the form includes it), the form page URL (pass this as a hidden field), their message verbatim, and the UTM source.

For forms that don't have a UTM field, you can pass the referrer URL as a hidden field using JavaScript: document.getElementById('hidden_referrer').value = document.referrer; on form load. It's not perfect, but it tells you whether the lead came from a blog post, organic search, or a specific campaign page — which changes how the sales rep opens the conversation.

Failed n8n workflows are silent by default — they show up as red executions in the dashboard, but nobody knows unless they're actively watching. For any workflow that runs on a schedule or processes incoming data, a failure that goes unnoticed for 6 hours is a real problem: lead notifications not sent, invoices not processed, reports not delivered. This monitoring workflow fixes that without requiring you to log into n8n to check.

The setup: a Schedule Trigger fires every 15 minutes. An HTTP Request node calls the n8n API at /api/v1/executions?status=error&limit=50 with your n8n API key as a bearer token. The response includes all failed executions from the last run period. A Code node compares the execution IDs against a Google Sheets log of already-reported failures, filters out the ones already sent, and groups the new ones by workflow name. For each new group, a Slack message fires to #ops with the workflow name, failure count, time of last failure, and a direct URL to that workflow's execution log in n8n.

The Google Sheets deduplication step is what makes this useful rather than noisy. Without it, the same failed execution gets reported every 15 minutes until someone fixes it. With it, each failure fires once, and the ops team sees one message per incident — not 24 messages by the time they get back from lunch. The Sheets row gets updated with reported_at timestamp so you can also tell how long an issue went unresolved.

Teams that rely on standups to know what everyone's working on are essentially using a synchronous meeting to share information that could be async. This workflow doesn't replace standups — it makes them better by giving everyone the context before they join. At 8:45am every weekday, the workflow pulls the day's priorities from wherever the team actually tracks them.

For teams using Linear: the HTTP Request node calls the Linear GraphQL API to get all issues assigned to team members with a "In Progress" or "Today" status label. For Notion: the Notion node queries a database filtered by the "Today" date property. The Code node formats this into a Slack message grouped by person — each person's name followed by their 1–3 items for the day. The key formatting choice is posting to Slack with reply_broadcast: false in a designated thread rather than as a top-level message — this keeps the main channel clean while giving everyone a place to add updates during the day.

The Linear GraphQL query that does the filtering is the most setup-intensive part. You need to know your team ID and label IDs, which you can get from the Linear settings page. Everything else — the Slack formatting, the schedule trigger — is straightforward. Once it's running, teams consistently report that standups get shorter because people already know the context before they show up.

A Slack ping every time revenue comes in sounds frivolous until you've experienced it on a team. It's not about the $49 — it's about the signal that the product is working, and the fact that everyone on the team knows it in real time. Stripe's native notifications are email-only, which means they go unread. A Slack message in #revenue is impossible to miss and impossible to ignore.

The workflow uses the Stripe Trigger node set to charge.succeeded events. The payload includes the customer email, amount, currency, and the subscription plan name (if applicable). After the Stripe node, an HTTP Request node calls the Stripe API to pull the current month's total revenue using the balance transactions endpoint — /v1/balance_transactions?type=charge&created[gte]={start_of_month} — and sums the amounts. The Slack message includes: the customer name, plan, amount paid, and the month-to-date total. You always know exactly where you are relative to last month or your MRR goal without opening Stripe.

One practical detail: Stripe amounts are in cents (integer), so amount / 100 in the Set node before formatting. Also set the Stripe Trigger's production/test mode to match your environment — test mode fires on Stripe test events only, which is useful while you're building and testing the workflow before going live.

Customer feedback is only useful if the right people see it. A bug report that lands in #marketing is a bug report that doesn't get fixed. A feature request that lands in #support gets logged nowhere. The usual solution is to read every submission and paste it to the right channel manually — which takes time and still has coverage gaps when inboxes are busy.

This workflow routes feedback automatically. The Typeform Trigger (or Webhook for any other survey tool) receives the submission. The AI Agent node — set up with GPT-4o and a system prompt — reads the response and classifies it into one of four categories: Bug Report, Feature Request, Billing Issue, or General Feedback. The prompt is straightforward: you describe each category in 1–2 sentences and tell the model to return a JSON object with { "category": "Bug Report", "urgency": "high", "one_line_summary": "..." }. The IF node then reads the category field and branches to the appropriate Slack channel: #engineering for bugs, #product for feature requests, #billing for billing issues, #cs-general for everything else.

The urgency field in the AI response lets you add a second condition: if urgency is "high", tag the channel lead by name in the Slack message (@username in Block Kit pulls attention even in busy channels). For normal urgency, the message is untagged. This prevents the support team from being pinged for every "love the product" NPS response while ensuring critical bug reports get immediate attention.

This is the most technically involved of the seven, but also the most impactful for operations teams. Purchase requests, time-off approvals, content sign-offs, vendor onboarding — any decision that needs a manager's explicit sign-off before an action is taken. The current state at most companies: a form, then an email, then a Slack message asking if someone saw the email, then the actual decision three days later. The approval flow collapses all of that into one Slack message that gets answered in minutes.

The architecture uses two separate n8n workflows. Workflow A receives the request (via a Google Form webhook or internal tool), formats the data using a Set node, and sends a Slack message with Block Kit interactive buttons — Approve and Reject. The button payload is configured with a response URL that points to Workflow B's Webhook trigger URL. When the manager clicks a button, Slack sends a POST request to Workflow B with the action ID (approve/reject), the message context, and the user who clicked. Workflow B then records the decision in a Google Sheet (timestamp, decision, approver), notifies the requester via email or Slack DM with the outcome, and — if approved — triggers whatever action was requested (creates a purchase order draft, updates a status in your project management tool, etc.).

The two-workflow design is intentional: Workflow A can trigger immediately without waiting, and Workflow B only runs when someone actually clicks a button. Trying to do this in one workflow with a Wait node works but creates issues when n8n restarts — the wait state doesn't always survive. The two-webhook pattern is more reliable in production.