Most automation guides start with theory. This one starts with five workflows you can import into n8n and have running in under an hour. Each one solves a real problem I've hit while leading engineering teams — and each one is something you can recreate in minutes.
If you've been running a team for more than a few months, you've probably noticed the same pattern: about 30% of your week is spent on things that aren't really decisions. They're reactions. Someone opened a PR and nobody noticed for two days. The weekly status email took 45 minutes to compile. A staging server went down and you found out from a client.
n8n is a self-hosted automation platform that connects to basically everything — GitHub, Slack, databases, APIs, email — and lets you build workflows visually. It's open source, runs on a $12/month VPS, and unlike Zapier, your data never leaves your infrastructure.
Here are five workflows I set up first on every team I lead.
1. Slack Alerts for GitHub Pull Requests
The problem: PRs sit unreviewed for hours (or days) because no one saw the notification buried in their GitHub inbox. Code review becomes the bottleneck, not the code itself.
What this workflow does: When a PR is opened or marked ready for review, it posts a formatted message to your team's Slack channel with the PR title, author, description preview, and a direct link. When the PR is approved or merged, it updates the thread.
Trigger: GitHub Webhook → Pull Request events
Filter: opened, ready_for_review, closed (merged)
Transform: Extract title, author, body preview, URL
Output: Slack message to #engineering channel
Thread: Update original message on approval/mergeThe key detail most people miss: you want to thread updates onto the original message, not post a new message for every event. Otherwise your Slack channel turns into noise. n8n handles this by storing the Slack message timestamp from the first post and using it as the thread_ts parameter on follow-up messages.
Set up a separate webhook for each repository, or use n8n's Switch node to route events based on $json.repository.name — that way you can send frontend PRs to #frontend and backend PRs to #backend without duplicating the workflow.
The Nodes
- GitHub Trigger — listens for
pull_requestevents - Switch — routes based on
action(opened vs. closed) - Set — formats the Slack message payload
- Slack — posts to channel (new PR) or replies to thread (updates)
{
"nodes": [
{
"name": "GitHub Trigger",
"type": "n8n-nodes-base.githubTrigger",
"parameters": {
"events": ["pull_request"],
"owner": "your-org",
"repository": "your-repo"
}
},
{
"name": "Filter PR Action",
"type": "n8n-nodes-base.switch",
"parameters": {
"dataPropertyName": "action",
"rules": {
"rules": [
{ "value": "opened" },
{ "value": "ready_for_review" },
{ "value": "closed" }
]
}
}
},
{
"name": "Post to Slack",
"type": "n8n-nodes-base.slack",
"parameters": {
"channel": "#engineering",
"text": "New PR: {{ $json.pull_request.title }}",
"attachments": []
}
}
]
}2. Automated Weekly Status Reports
The problem: Every Monday morning you spend 30–45 minutes pulling data from GitHub, Jira, and your deployment logs to write a status update. It's the same structure every week — just different numbers.
What this workflow does: Every Monday at 8am, the workflow pulls the previous week's data from GitHub (PRs merged, issues closed), your project management tool (tickets completed, sprint progress), and your deployment pipeline (deploys shipped). It formats everything into a clean summary and drops it in Slack or sends it via email.
Trigger: Schedule → Monday 8:00 AM
Fetch: GitHub API → merged PRs (last 7 days)
Fetch: Jira API → completed tickets (last 7 days)
Fetch: Deploy log API → successful deploys
Transform: Aggregate counts, format summary
Output: Slack #leadership channel + email to stakeholdersThe workflow uses n8n's HTTP Request nodes to hit each API in parallel (n8n supports parallel execution paths), then a Merge node to combine the results before formatting. The output template uses simple Markdown that renders cleanly in both Slack and email.
The best status report is the one nobody had to write.
I've been running a version of this for over a year. The leadership team gets a consistent, data-backed update every week — and I get 45 minutes back every Monday.
3. Uptime Monitoring with Escalation
The problem: Your monitoring tool sends alerts, but they go to a channel that everyone's muted. You find out about downtime from customers, not from your systems.
What this workflow does: Pings your critical endpoints every 5 minutes. If a check fails, it waits 2 minutes and retries. If it fails again, it posts to Slack and sends an SMS to the on-call engineer. If it's still down after 15 minutes, it escalates to you directly.
You absolutely can. But if you're already running n8n, adding uptime checks keeps everything in one place — and you get full control over the escalation logic. The point isn't to replace dedicated monitoring; it's to make sure alerts actually reach humans.
The escalation chain is the key part. Most monitoring tools either alert everyone immediately (alert fatigue) or alert one person (single point of failure). This workflow implements a simple but effective pattern:
- First failure: Retry after 2 minutes (transient issues resolve themselves)
- Second failure: Alert #ops-alerts in Slack + SMS to on-call
- Still down at 15 min: Escalate to engineering lead
- Still down at 30 min: Page the CTO (that's me — and I want to know)
4. New Hire Account Provisioning
The problem: A new developer starts on Monday. By Wednesday they still don't have access to GitHub, Slack, the staging environment, and the VPN. You've sent five different "can you add X to Y" messages across three platforms.
What this workflow does: You fill out a simple form (n8n has built-in form triggers) with the new hire's name, email, role, and team. The workflow automatically creates or invites them to GitHub (with the right team permissions), Slack (with the right channels), your project management tool, and sends them a welcome email with first-day instructions.
Trigger: n8n Form → New hire details
Branch: Switch on role (engineer, designer, PM)
Parallel:
→ GitHub API → invite to org + add to team
→ Slack API → invite to workspace + join channels
→ Jira API → create account + add to project
→ Email → send welcome packet
Log: Append row to onboarding spreadsheetThe Switch node is doing the heavy lifting here — different roles get different permissions. An engineer gets added to the GitHub org and #engineering; a designer gets Figma access and #design. The role-based branching means you configure it once and every hire gets exactly the right access from day one.
5. Deploy Notifications to Stakeholders
The problem: You shipped a feature on Thursday. On Monday, the product manager asks "when is this going live?" It's been live for four days. Nobody told them.
What this workflow does: When a deploy succeeds (triggered by your CI/CD pipeline's webhook), the workflow pulls the list of merged PRs since the last deploy, formats a human-readable changelog, and posts it to a #releases channel that stakeholders actually follow. If any PR has a linked Jira ticket, it includes the ticket title and a link.
Trigger: Webhook → CI/CD deploy success event
Fetch: GitHub API → commits since last tag
Parse: Extract PR numbers from merge commits
Enrich: Jira API → get ticket titles for linked PRs
Format: Build changelog (grouped by type: feature/fix/chore)
Output: Slack #releases + optional email digestThe trick is grouping changes by type. If your team uses conventional commits (feat:, fix:, chore:), the workflow can categorize them with a simple regex. Stakeholders see a clean list of new features and bug fixes — not a wall of commit hashes.
Add a 10-minute delay between the deploy trigger and the Slack post. That gives you time to catch a rollback before the "we just shipped X" message goes out.
Getting Started
To set these up in n8n:
- Install n8n (self-hosted or cloud —
npx n8ngets you running locally in minutes) - Import the workflow JSON via the Workflows menu
- Add your credentials (GitHub token, Slack bot token, etc.)
- Update the channel names and repository references to match your setup
- Activate the workflow
Each workflow is designed to be a starting point. Modify the Slack message templates, add extra notification channels, adjust the escalation timing — whatever fits your team. The point is to stop doing manually what a machine can do in milliseconds.
