Alerts in Slack and Signed Webhooks

Alerts in Slack and Signed Webhooks

Email tells each teammate about new critical and high issues. Alert integrations go further: they post to the places your team watches all day. Workspace owners and admins connect them from Integrations → Alerts; integrations are part of the Pro plan and above, and of the trial.

Slack

1. Open Integrations → Alerts → Slack and click Connect.
2. Approve the FortWatch app in Slack. If your Slack workspace requires admin approval for apps, a Slack admin approves it once.
3. Pick a default channel, or let FortWatch create one. For a private channel, type /invite @FortWatch in it first, then click Refresh.
4. Click Send test, then Finish.

Each new issue posts a message with its severity, asset, what is wrong and a link. When the issue is fixed, dismissed or re-rated, FortWatch edits that message and replies in its thread, so the channel never shows a problem that is already gone. Message options can add @here to a critical issue's first message and mention the issue's assignee, matched by email.

Slack also brings FortWatch AI: DM the app or mention @FortWatch in a channel. It answers each person with what their FortWatch role allows, matched by email or by a one-time account link.

Signed Webhooks

1. Open Integrations → Alerts → Webhook and paste an HTTPS URL: a Zapier Catch Hook, a Make custom webhook, an n8n Webhook node or your own service.
2. Copy the signing secret (whsec_…). FortWatch shows it once.
3. Click Send test so your tool learns the fields.

Every delivery follows the Standard Webhooks specification: a JSON POST with webhook-id, webhook-timestamp and webhook-signature headers, signed with HMAC-SHA256. Verify the signature before you trust a delivery. A failed delivery is retried with the same webhook-id, so your receiver can drop duplicates. The payloads, the event list and verification code for Node.js, Python, Go and PHP are at docs.fortwatch.ai/webhooks.

Routes and Rules

A route sends one scope to one destination: the whole workspace, a project or one asset. The most specific route wins, and several routes on the same scope all fire. Each route has its own rules:

• Events — new, reopened, fixed, dismissed and re-rated issues, comments, SLA due soon and breached, scan finished or failed, and an asset that stops answering.
• Minimum severity — below it, nothing new is sent; a follow-up about an issue the route already posted still goes out.
• Skip the first scan — a new asset's first scan does not flood the channel.
• Delivery — instant, or a daily or weekly digest at 08:00 in the route's time zone.
• Quiet hours — messages are held until the window ends; a critical issue still goes out.
• Storm guard — past a set number of messages from one scan, the rest fold into one summary.

The Delivery Log

Each connection keeps a log of every message it sent or held, with the event, issue, channel and result. A held message says why it waits; a failed one says what went wrong and can be sent again. A destination that stops working pauses its route and tells the owners, and while it is paused its events fall through to the next less specific route.