Why should you automate notifications from your kanban board?
Automated notifications eliminate the gap between when something changes on your board and when the right person knows about it. When a card moves to Review, the reviewer should know immediately - not when they next open the board. When a due date is 24 hours away, the assignee should get a reminder - not discover it was overdue yesterday. When a deploy fails, the team should see an alert in Slack within seconds - not discover it during the next standup.
Without automation, the notification burden falls on humans. Someone has to remember to ping the reviewer after opening a PR. Someone has to check due dates daily and remind assignees. Someone has to watch the CI dashboard and alert the team on failures. These are exactly the kinds of tasks that get forgotten under pressure - which is exactly when they matter most.
The key to good notification automation is specificity. Do not send a firehose of every board change to a single Slack channel - that creates noise that people learn to ignore. Instead, route specific events to specific channels with specific context. A card moving to Review goes to the reviewer as a DM with a link. A due date approaching goes to the assignee. A deploy failure goes to the engineering channel. The goal is that every notification is actionable by the person who receives it.
How do polling and webhook patterns differ?
There are two fundamental approaches to detecting changes for notification: polling (your script asks the API for updates on a schedule) and webhooks (the source system pushes events to your endpoint). Each has tradeoffs that affect implementation complexity, latency, and infrastructure requirements.
Polling approach
A polling script runs on a cron schedule - typically every 5 to 15 minutes - and reads the board state from the REST API. It compares the current state to a stored snapshot of the previous state and identifies changes: cards that moved columns, new cards created, due dates approaching, assignments changed. For each change, it fires the appropriate notification.
Advantages: simple to implement (a single script and a cron job), no inbound infrastructure required, works with any API that supports GET requests. Disadvantages: latency equal to the poll interval (a 5-minute poll means up to 5 minutes of delay), unnecessary API calls when nothing has changed, and complexity in tracking state between runs.
For most teams, polling is the right starting point. The 5-minute delay is acceptable for all but the most time-sensitive notifications, and the implementation requires nothing beyond a script and a cron runner (even a GitHub Action on a schedule works).
Webhook approach
Webhooks are event-driven: when something changes, the source system sends an HTTP POST to a URL you control with the event details. This gives near-instant notifications with no unnecessary API calls. The tradeoff is that you need to host a webhook endpoint - a serverless function, a small web server, or a service like Pipedream or Make that can receive POST requests.
For teams that already have serverless infrastructure (AWS Lambda, Cloudflare Workers, Vercel Functions), webhooks are straightforward. For teams without that infrastructure, the overhead of hosting and monitoring a webhook endpoint may not be worth the latency improvement. Evaluate based on how time-sensitive your notifications are: due date reminders are fine with 5-minute polling; incident alerts may need near-instant webhook delivery.
| Factor | Polling | Webhooks |
|---|---|---|
| Latency | Equal to poll interval (1-15 min) | Near-instant (seconds) |
| Infrastructure | Cron job only | Hosted endpoint required |
| API load | Constant (even when nothing changes) | Zero when idle |
| Implementation complexity | Low - diff two snapshots | Medium - handle events, verify signatures |
| State management | Must persist previous snapshot | Stateless event handling |
| Best for | Due date reminders, weekly digests, reports | Incident alerts, deploy notifications, real-time sync |
Which channels should you route notifications to?
The channel strategy matters more than the implementation. A perfectly automated notification system that dumps everything into one Slack channel is worse than no automation at all - it creates noise that people mute, which means the important alerts get lost with the trivial ones.
Slack and Discord
Slack and Discord are the most common notification targets because they are where engineering teams already communicate. Both support incoming webhooks - a URL you POST a JSON payload to, and the message appears in the configured channel.
Set up at least two channels: a high-urgency channel (#engineering-alerts) for build failures, deploy issues, and overdue cards; and a low-urgency channel (#board-activity) for card movements, new assignments, and status changes. People keep the alerts channel unmuted and check the activity channel when they want context.
For individual notifications - a reviewer being assigned, a personal due date reminder - use direct messages. Both Slack and Discord support posting DMs via bot tokens. This is the most targeted notification channel and the one least likely to cause fatigue.
Email is the right channel for stakeholders who are not in your team's Slack workspace - clients, external collaborators, executives who check email but not Slack. Weekly digest summaries (cards completed, cycle time metrics, upcoming due dates) work well as email. Real-time card-movement notifications do not - email is too slow and too noisy for operational updates.
Routing matrix
| Event type | Channel | Audience | Urgency |
|---|---|---|---|
| Build failure on main | Slack #engineering-alerts | Full engineering team | High |
| Deploy succeeded | Slack #deploys | Engineering + stakeholders | Medium |
| Card moved to Review | Slack DM to reviewer | Assigned reviewer | Medium |
| Due date within 24 hours | Slack DM to assignee | Card assignee | Medium |
| Card moved between columns | Slack #board-activity | Interested parties | Low |
| Weekly board summary | Email or Slack #status | Leadership, stakeholders | Low |
How do you prevent notification fatigue?
Notification fatigue is the primary failure mode of notification automation. Teams set up alerts for everything, get overwhelmed within a week, mute the channel, and lose the important alerts along with the trivial ones. Preventing fatigue requires deliberate filtering and batching.
Filter self-actions
Never notify someone about an action they performed themselves. If a developer moves their own card to Review, they already know - a Slack message telling them what they just did is noise. Your script should compare the actor (the user who made the change) to the notification recipient and skip the notification if they match.
Batch non-urgent updates
Not every event needs a real-time notification. Card movements, new comments, label changes - these are informational, not urgent. Instead of firing one message per event, collect them and send a digest. A daily digest at 9 AM summarizing yesterday's board activity gives the team awareness without the interruption. A weekly digest on Monday morning works for leadership.
Use threads for context
When multiple notifications relate to the same card, post them as replies to a thread rather than as new messages. Slack and Discord both support threading. A card that moves from In Progress to Review to Done generates three notifications - as a thread, it is one card's journey; as three separate messages, it is noise.
Escalation tiers
Not all due dates are equal. A card due in 24 hours gets a DM. A card that is now overdue gets a channel message. A card that has been overdue for three days gets a message to the team lead. This escalation pattern ensures that missed deadlines get progressively more visible without overwhelming people on day one.
How do you set up notifications for incident response?
Incident response has different notification requirements than routine project management. Incidents need immediate, high-visibility alerts that reach the on-call engineer within seconds, not minutes.
The pattern for incident response automation: a monitoring tool (PagerDuty, Datadog, Grafana) detects an anomaly and fires a webhook to your automation endpoint. The automation creates a card on the incident response board with severity, affected service, alert details, and a link to the monitoring dashboard. Simultaneously, it posts to the incident channel in Slack with the card link and @-mentions the on-call engineer.
For incident cards specifically, include structured metadata: severity level (P0-P3), affected service, detection time, customer impact estimate, and a link to the runbook. This structured data makes the card immediately actionable rather than requiring the on-call engineer to dig through monitoring dashboards for context.
How do you get started with notification automation?
Start with one notification that solves a real pain point your team has today. The most common starting point: due date reminders. A script that runs daily at 9 AM, checks for cards with due dates within 24 hours, and sends a Slack DM to each assignee. It is simple to build, immediately useful, and low-risk (worst case, someone gets a reminder they did not need).
Implementation: a cron job (or GitHub Action on a schedule) calls the Flux REST API to list cards with upcoming due dates, cross-references assignees, and posts to the appropriate Slack channel or DM via incoming webhook. The entire script is typically under 50 lines of code.
For no-code alternatives, Zapier and Make both support schedule triggers with API calls and Slack/Discord/email outputs. The no-code automation guide covers the setup. For building custom polling scripts against the REST API, see the API integrations guide.