Notifications and channels

This page explains how an alert reaches you, and every setting that decides who gets it, where and when. It is for every member (for their personal preferences) and for project administrators (for webhooks).

How an alert travels

Three settings apply, in this order:

1. The project’s prioritisation policy: which CVEs raise an alert, based on their scores and exploitation signals (project settings, Alerts page).
2. The project’s workflows: every notification goes through a workflow. Their tiles choose the channels: bell, e-mail, webhooks, ticket (Workflows).
3. Each recipient’s frequency: the e-mail goes out straight away or in a daily or weekly digest (your preferences).

Bell

In-app notification. In-app notification tile. Always immediate.

E-mail

Send email tile. Immediate or digest, depending on each recipient.

Webhooks

Slack, Microsoft Teams, Discord or raw JSON. Call webhooks tile. Always immediate.

Tickets

Jira, GitLab or GitHub, set up in the project’s Integrations page. Create a ticket tile.

A workflow runs for each project member who sees its alerts (“View alerts” right, every role by default), plus the project owner: since the stack and the alerts belong to the project, the whole team is told. Everyone gets their own notification and their own e-mail, according to their own preferences; the alert, its case and the webhook call exist only once for the project.

The bell

The bell, top right, gathers your in-app notifications. A dot shows there are unread ones.

1. The bell: a click opens the panel; Esc or a click elsewhere closes it.
2. The header: the number of unread notifications and Mark all as read.
3. A notification: a black dot marks it as unread; a pill gives its category (CVE severity, end of life…).

• The panel shows the 30 most recent notifications and refreshes every 30 seconds.
• Clicking a notification marks it as read and opens what it is about: the project alert for a CVE, the page given by a NIS2 notice, otherwise the CVE page or the alert list.
• You will find workflow alerts there (new CVE, CVE updated, PoC published, added to KEV, CVE now exploited, end of life or support, new release, HTTPS certificate), NIS2 notices, and team messages (invitation received or accepted, role changed, added to or removed from a project, case assigned to you). Assigning a case notifies the assignee through the bell and by e-mail (Assignments preference, below), with no workflow; assigning several alerts at once gives a single notification, which opens the alert list filtered on My assignments (see Assigning the case).
• A notification sent by a workflow live test is prefixed with [TEST].

Your preferences (e-mail frequency)

Each member chooses when their alert e-mails go out. Open Settings (your profile menu, bottom left), then the Notifications tab. The Manage notifications link in the e-mails leads to the same place.

1. The personal settings tabs.
2. Alert e-mail frequency: Immediate, Daily digest or Weekly digest.
3. Delivery time (and Delivery day for the weekly digest).
4. The reminder about urgent alerts, which never wait for the digest.

Frequency	What you receive
Immediate	each alert goes out as soon as it is detected, grouped by project and type.
Daily digest	one e-mail a day at the chosen time, across all projects, most pressing first.
Weekly digest	one e-mail a week, on the chosen day and time.

1. Choose the frequency. For a digest, choose the time (and day).
2. Click Save; Cancel discards the change.

The rules that apply:

• Only e-mail changes: the bell, webhooks and workflows stay immediate.
• Urgent alerts go out at once, even in digest mode: a CVE added to the CISA KEV catalogue, a CVE that becomes exploited, any CVE already exploited (KEV, EUVD, CERT-FR) at the time of sending, and the NIS2 deadlines that cannot wait: incident reporting deadline, overdue fix, escalation to the security lead.
• The time is read in your browser’s time zone at the moment you save (shown under the lists). Daylight saving time is taken into account.
• Below the settings, Next digest gives the date of the next send (shown in your browser’s time zone) and the number of alerts waiting.
• Changing the frequency picks up waiting alerts: they go out or are rescheduled for the next slot.

Assignment e-mail

Under the frequency, the Assignments switch (on by default) decides whether you get the “A CVE alert has been assigned to you” e-mail when a colleague assigns you a case: the CVE, its severity and CVSS score, the exploitation signals, the project, who assigned it and the link to the alert. It is saved as soon as you flip it.

• This e-mail goes out at once, whatever the frequency: assigned work does not wait for the digest.
• Assigning several alerts at once gives a single summary e-mail listing them (ten at most, then “And N more”), with the View my assignments button.
• You do not get one when you assign yourself, or when an existing assignment is made again.
• Turning the switch off only stops the e-mail: the bell notification stays. The one-click unsubscribe of an e-mail stops it too.

Unsubscribing from an e-mail

Every alert e-mail contains an unsubscribe link. If it has been used, a banner says so in this tab: no alert is e-mailed to you any more, in any project. The Resubscribe button cancels it. Service e-mails (address verification, password) are not affected.

Project webhooks

A webhook sends the alert to another tool: a Slack or Teams channel, a Discord server, a SIEM, a script. Webhooks are declared in the project settings: Workspace › Organizations, your organisation, Projects page, the project, then its Integrations page, Webhooks section.

1. The Webhooks section of the project’s Integrations page.
2. The project’s webhook list, with the maximum allowed by the plan (Unlimited here).

1. Click Add.
2. Give a Name (e.g. “Slack #alerts”) and the URL provided by the receiving tool.
3. Click Add. The webhook is created Active, and its signing secret is displayed: copy it, it will not be shown again.

The Signing secret window opens only once: copy the secret into the receiving tool, then click I have copied the secret. It will never be shown again; only a new secret can replace it.

• Each webhook has an Active / Inactive switch, applied at once, and a ⋯ menu (also on a right-click on its row): Edit (name and URL, in a window), Regenerate secret and Delete (with confirmation).
• The address is only shown shortened (the host, followed by “…”): for Slack, Teams or Discord, it carries a token itself. When editing, the URL field starts empty: left empty, it keeps the stored address; only enter a URL to replace it.
• Regenerate secret asks for confirmation, then shows the new secret in the same window as at creation. The old one stops working at once: update the tool that checks the signature.

• The URL must use http or https, on port 80, 443, 8080 or 8443, and point to a public address: an internal address is refused, both when saving and on every send.
• A webhook receives nothing on its own: a workflow needs a Call webhooks tile. It targets all the project’s active webhooks or a single one, and chooses the format.
• Webhook sending can also be switched off for the whole project: it is a project setting, shared by the team, that only someone with the Edit webhook right can change, with the Send webhooks switch of the Team notifications card (project settings, General page). When it is off, the tile does nothing and the workflow run log says “webhooks désactivés dans les réglages du projet”.

Format	What is sent
Raw JSON (default)	a JSON object: event, project, date, then as applicable the CVE (identifier, severity, CVSS and EPSS scores, PoC, KEV, description, watched item), the product and its end-of-life date, or the URL and its certificate.
Slack	a text message: title and main facts.
Discord	the same message, in Discord format.
Microsoft Teams	an Adaptive Card, for a Teams webhook created with Power Automate.

The call is a JSON POST, without following redirects, abandoned after 10 seconds. It goes out after the alert is saved, once per project event (not once per member). A transient error (timeout, 429 or 5xx response) is retried later, up to six attempts; any other error response abandons it. The workflow’s run log shows queued, then sent or error. With the tile’s AI analysis option, the message also carries a short analysis. The message labels are in the language of the person who created the webhook.

Verifying the signature

Every call carries two headers:

Header	Value
X-TWA-Timestamp	the send time, in Unix seconds.
X-TWA-Signature	sha256= followed by the hex HMAC-SHA256 of X-TWA-Timestamp + "." + raw body, computed with the webhook’s secret.

On the receiving side, recompute the HMAC over the raw body received (before any JSON decoding), compare it in constant time, and reject timestamps older than five minutes to rule out replays. Keep the URL secret too: for Slack, Teams or Discord, it is enough to post in the channel.

Tip

To check a webhook without waiting for a real CVE, open the workflow, type a CVE into the test field and turn on Live send: the message goes out marked [TEST] (see Testing a workflow).

Who can do what: the section and the list are reserved for those with the View webhooks right; adding, editing (including enabling, disabling and regenerating the secret) and deleting are three separate rights (Create webhook, Edit webhook, Remove webhook). By default only the project’s administrators and owner hold them all; they can be set member by member or per group.

Plan: Free does not include webhooks (the section shows “Plan required”); Team allows 5 per project; Pro and Business, unlimited.

Dismissing a CVE or a component

A CVE is not muted: it is handled. A CVE that does not concern the project (false positive, component not exposed) is marked Not applicable from the alert’s tracking bar, with an optional reason posted as a comment (see Handling an alert › Dismissing a CVE). For a whole component, adjust the stack: raise its alert threshold or remove it.

A CVE closed as Not applicable can still come back if it becomes exploited: the project’s CVE now exploited workflow, if active, still sends its notice.

Frequently asked questions

I’m on the daily digest: will I miss an exploited vulnerability? No. KEV additions, CVEs that become exploited and CVEs already exploited go out immediately, outside the digest.

I no longer get any e-mail. Check the Notifications tab of your settings (unsubscription banner), then the project’s Workflows screen: an active workflow with the Send email tile must listen to the event, and Restrict recipients must not leave you out. Finally, if the platform’s email server is not configured, emails are not lost: they stay pending, are not marked as sent, and are retried every 30 minutes until sending is possible.

A colleague wants no more alerts about a retired component, but I still do. The stack applies to the whole project. To filter per person, use Restrict recipients in the workflow’s e-mail tile.

See also

Workflows

Handling an alert

Projects

Account settings