Notification Channels

Nobody watches a dashboard. Notification channels push alerts into the places your teams already work, so a critical advisory reaches an on-call engineer rather than waiting for someone to open the console.

Channels are configured per workspace under Settings -> Notification Channels, and require the Manage connectors permission or workspace admin rights.

Two channels on one workspace, each with its own categories and thresholds.

Channel Types

Microsoft Teams posts alerts into a channel using an incoming webhook URL created in Teams. Create the incoming webhook on the Teams channel first, then paste the URL into ShieldedStack.

Webhook sends a JSON payload to an endpoint of your own, for routing into an incident tool, a SIEM, a ticket queue, or an internal service.

Select a type when adding a channel and the form lists the fields it needs. For a webhook these cover the endpoint URL, the HTTP method, a request timeout, and an optional shared secret with control over whether it is sent as a header or a query parameter and under what name.

Deciding What Each Channel Receives

Every channel is filtered independently, which is what makes several channels useful rather than redundant.

• Alert categories select whether the channel receives vulnerability alerts, license change alerts, or both.
• Minimum severity sets the floor for vulnerability alerts. Anything below it is not sent. Set it to Any severity to receive everything.

A common arrangement is two channels on the same workspace: one to an on-call Teams channel restricted to Critical and High vulnerabilities, and one webhook into a ticket queue that takes everything including license changes, where it can be worked through at a normal pace.

Channels can be disabled without being deleted. Disable one while an endpoint is under maintenance rather than removing it and rebuilding the configuration afterwards.

Channel filtering decides what gets sent. The Vulnerability Alert Cooldown on the Settings page decides what gets raised in the first place, and applies to the portal and every channel alike. If a channel is repeating itself, check the cooldown before adjusting the channel. See Alerts and Triage.

Webhook Payloads

Webhook deliveries are JSON. Every payload has an alertType and an alert object, so a receiver can switch on the type and read the fields it cares about.

A vulnerability alert:

{
  "alertType": "vulnerability",
  "alert": {
    "id": "...",
    "severity": "High",
    "title": "Vulnerability found in 'example-package'@1.4.2'",
    "description": "Short advisory description",
    "createdAtUtc": "2026-09-02T09:14:22Z",
    "ecosystem": "Npm",
    "packageName": "example-package",
    "version": "1.4.2",
    "cveId": "CVE-2026-12345",
    "cvss": "8.7",
    "firstPatchedVersion": "1.4.3",
    "remediation": "Upgrade guidance for this ecosystem",
    "observation": { }
  }
}

A license change alert:

{
  "alertType": "licenseChange",
  "alert": {
    "id": "...",
    "severity": "Warning",
    "title": "License changed for 'example-package'",
    "description": "License changed from 'MIT' to 'BUSL-1.1'",
    "createdAtUtc": "2026-09-02T09:14:22Z",
    "ecosystem": "Npm",
    "packageName": "example-package",
    "previousLicense": "MIT",
    "newLicense": "BUSL-1.1"
  }
}

Treat the payload as additive: build receivers that read the fields they need and ignore the rest, so a future field does not break your integration.

Verifying Deliveries

Set a shared secret and have your receiver reject requests that do not carry it. The secret is sent either as a request header or as a query parameter, whichever placement you choose, under the name you give it. A header is the better default, because query parameters have a habit of ending up in access logs.

Point the endpoint at something you control and confirm the first delivery arrives before relying on the channel. A webhook that silently fails looks exactly like a workspace with no alerts.

Choosing Thresholds

The temptation is to send everything everywhere, which produces a channel people mute within a fortnight. A channel is useful only if its arrival rate matches the attention it is meant to get.

Destination	A reasonable setting
On-call or incident channel	Vulnerability alerts only, minimum severity Critical or High
Team channel for the owning squad	Vulnerability and license alerts, minimum severity Medium
Ticket queue or SIEM	All categories, any severity, deduplicated on your side
Compliance or legal	License alerts only

If a channel is too noisy, the fix is usually a higher severity floor or a longer cooldown, not turning the channel off. If it is too quiet, check that the alerts exist in the console at all before assuming delivery is broken.