Why Slack for DDoS Alerts
Most infrastructure teams already live in Slack. When an attack begins, the fastest path to awareness is posting to the channel where your engineers are already working. Email notifications sit unread. SMS messages get buried. But a well-formatted Slack alert in your #network-alerts channel gets eyes within seconds.
Flowtriq's Slack integration sends structured Block Kit messages that include everything your team needs to begin triage: the target IP, attack vector classification, packets per second, bits per second, the node reporting the event, and a direct link to the incident in the Flowtriq dashboard. No context switching, no digging through logs.
In this guide, we will walk through the full setup process: creating a Slack webhook, configuring Flowtriq to send alerts, routing different severity levels to different channels, formatting alerts with Block Kit, and setting up quiet hours so informational events do not wake anyone up at 3 AM.
Prerequisites
Before you begin, make sure you have:
- A Flowtriq account with at least one active node reporting traffic data
- Admin or owner permissions on your Slack workspace (needed to create an incoming webhook)
- The Slack channel(s) where you want alerts to appear, already created
The entire setup takes about 5 minutes. No code deployment is required because Flowtriq handles the webhook delivery from our side.
Step 1: Create a Slack Incoming Webhook
Navigate to the Slack API dashboard and create a new app (or use an existing one). Select "From scratch" and choose your workspace. Once the app is created, go to Features > Incoming Webhooks and toggle the feature on.
Click Add New Webhook to Workspace and select the channel where you want Flowtriq alerts to appear. Slack will generate a webhook URL that looks like this:
https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX
Copy this URL. You will paste it into Flowtriq in the next step.
If your team uses multiple channels for different severity levels, create a separate webhook for each channel. For example:
#ddos-criticalfor high and critical alerts,#ddos-monitoringfor info and warning events.
Step 2: Configure the Alert Channel in Flowtriq
In the Flowtriq dashboard, navigate to Settings > Alert Channels and click Add Channel. Select "Slack" as the channel type and fill in the configuration:
{
"channel": "slack",
"name": "Slack - Critical Alerts",
"webhook_url": "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXX",
"severity_filter": ["high", "critical"],
"format": "block_kit",
"include_resolve": true
}
The severity_filter field controls which alert severities are sent to this channel. You can specify any combination of info, warning, high, and critical. If you omit the field, all severities are sent.
The include_resolve field tells Flowtriq to send a follow-up message when an attack ends. This is useful for tracking incident duration directly in Slack without switching to the dashboard.
Setting Up a Second Channel for Low-Priority Events
For teams that want visibility into all events without cluttering the critical alerts channel, add a second Slack channel:
{
"channel": "slack",
"name": "Slack - Monitoring",
"webhook_url": "https://hooks.slack.com/services/T00000000/B11111111/YYYYYYYY",
"severity_filter": ["info", "warning"],
"format": "block_kit",
"include_resolve": false
}
Info and warning events are typically short-lived anomalies. Sending resolve messages for these adds noise without much value, so we recommend leaving include_resolve set to false for the monitoring channel.
Step 3: Understanding the Block Kit Alert Format
When Flowtriq detects an attack and sends it to Slack, the message is formatted using Slack's Block Kit for maximum readability. Here is what the payload looks like for a high-severity SYN flood detection:
{
"blocks": [
{
"type": "header",
"text": {
"type": "plain_text",
"text": "DDoS Alert: SYN Flood Detected"
}
},
{
"type": "section",
"fields": [
{"type": "mrkdwn", "text": "*Severity:*\n:red_circle: High"},
{"type": "mrkdwn", "text": "*Target:*\n203.0.113.45"},
{"type": "mrkdwn", "text": "*Node:*\nedge-router-01"},
{"type": "mrkdwn", "text": "*Attack Vector:*\nSYN Flood"},
{"type": "mrkdwn", "text": "*Packets/sec:*\n847,320"},
{"type": "mrkdwn", "text": "*Bits/sec:*\n412 Mbps"}
]
},
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "*Baseline Deviation:* 12.4x above normal"
}
},
{
"type": "actions",
"elements": [
{
"type": "button",
"text": {"type": "plain_text", "text": "View Incident"},
"url": "https://flowtriq.com/incidents/abc123",
"style": "primary"
},
{
"type": "button",
"text": {"type": "plain_text", "text": "View PCAP"},
"url": "https://flowtriq.com/incidents/abc123/pcap"
}
]
},
{
"type": "context",
"elements": [
{"type": "mrkdwn", "text": "Flowtriq | Jun 7, 2026 14:32 UTC | Attack ID: abc123"}
]
}
]
}
The Block Kit format includes color-coded severity indicators using emoji: :white_circle: for info, :large_yellow_circle: for warning, :red_circle: for high, and :rotating_light: for critical. The action buttons link directly to the Flowtriq dashboard so engineers can review the incident, inspect the PCAP capture, and trigger mitigation actions without leaving the alert context.
Resolve Message Format
When an attack ends and include_resolve is enabled, Flowtriq sends a follow-up message to the same channel:
{
"blocks": [
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": ":white_check_mark: *Resolved:* SYN Flood on 203.0.113.45\n*Duration:* 4m 12s | *Peak:* 847,320 pps / 412 Mbps"
}
}
]
}
This gives the team a clear record of when the event started, when it ended, and how severe it was at peak, all in the same Slack thread.
Channel Routing Strategies
For larger teams, routing alerts by severity alone may not be sufficient. Here are three common routing strategies we see in production:
Strategy 1: Severity-Based Routing
This is the simplest approach. Create two channels: one for critical/high alerts and one for info/warning events. Most small-to-mid-size teams start here.
#ddos-critical: high, critical severity only#ddos-monitoring: info, warning severity only
Strategy 2: Node-Group Routing
If your team has separate on-call rotations for different parts of the infrastructure, route alerts based on node groups. You can configure multiple Slack channels in Flowtriq, each with a node_group_filter:
{
"channel": "slack",
"name": "Slack - Edge Routers",
"webhook_url": "https://hooks.slack.com/services/...",
"severity_filter": ["high", "critical"],
"node_group_filter": ["edge-us-east", "edge-us-west"],
"format": "block_kit"
}
This way, the US East team only sees alerts for their infrastructure, and the US West team sees theirs.
Strategy 3: Escalation Routing
Combine Slack with PagerDuty for a two-tier approach. All alerts go to Slack for visibility. Only high and critical events also trigger a PagerDuty page. This gives the entire team awareness while ensuring the on-call engineer gets a proper page for urgent events.
Configuring Quiet Hours
Quiet hours prevent low-priority alerts from posting to Slack during off-hours. This is particularly useful for the monitoring channel where info and warning events would otherwise accumulate overnight and create a wall of unread messages every morning.
To enable quiet hours, add the quiet_hours configuration to your alert channel:
{
"channel": "slack",
"name": "Slack - Monitoring",
"webhook_url": "https://hooks.slack.com/services/...",
"severity_filter": ["info", "warning"],
"format": "block_kit",
"quiet_hours": {
"enabled": true,
"start": "22:00",
"end": "08:00",
"timezone": "America/New_York"
}
}
Events that occur during quiet hours are not sent to Slack, but they are still recorded in the Flowtriq dashboard. They are not lost. Your team can review them the next morning using the dashboard's incident history view.
Quiet hours only affect the alert channels where they are configured. If you have a separate critical alerts channel with no quiet hours, high and critical events will always be sent regardless of time of day. We strongly recommend never applying quiet hours to your critical alerts channel.
Testing the Integration
After saving your Slack channel configuration, use the Test button in the Flowtriq dashboard to send a sample alert. This sends a realistic test payload to your Slack webhook so you can verify the formatting, channel routing, and permissions are working correctly.
The test message includes a [TEST] prefix in the header so your team knows it is not a real alert. If the test fails, check that:
- The webhook URL is correct and the Slack app is still installed in your workspace
- The Slack channel has not been archived or deleted
- Your Slack workspace does not have an IP allowlist that blocks Flowtriq's delivery servers
Troubleshooting Common Issues
Alerts Not Appearing in Slack
The most common cause is a stale webhook URL. Slack invalidates webhooks when the associated app is reinstalled or the channel is renamed. Regenerate the webhook and update the URL in Flowtriq.
Duplicate Alerts
If you see the same alert posted twice, check whether you have two Slack channels configured with overlapping severity filters. For example, a channel with ["warning", "high", "critical"] and another with ["high", "critical"] will both receive high and critical events.
Rate Limiting
Slack enforces a rate limit of roughly one message per second per webhook. During a large-scale attack with many simultaneous targets, Flowtriq batches alerts and delivers them within Slack's rate limits. If alerts are delayed by a few seconds during high-volume events, this is the rate limiter at work.
Tip: Pair your Slack alerts with PagerDuty integration for a complete alerting pipeline. Slack provides team-wide visibility; PagerDuty ensures the on-call engineer is paged for critical events.
Slack integration is available on all Flowtriq plans starting at $9.99/node/month. PagerDuty, Discord, and email channels are also included at no extra cost. Start your free trial to get DDoS alerts flowing into your team's Slack workspace in under 5 minutes.
Back to Blog