Notifications

Ctadel sends every new finding to your messaging or on-call tools. The setup has two parts: channels (where to send) under "Integrations", then alert rules (what to send) under "Notifications". Reading requires read:settings, changing requires update:settings.

Channels

Open "Settings", tab "Integrations", sub-tab "Notifications". The "Configured notifications" card lists your channels; the "Catalogue" card offers eight types.

Each channel has a "Name" and can be enabled, disabled, edited, tested or deleted. The test sends a dummy HIGH event titled "Test Notification" and answers "Test sent successfully". When editing, secret values (signing secret, PagerDuty key, Matrix token) are masked; leaving them masked keeps the stored value. Deleting a channel means: "Notification rules attached to this channel will stop sending."

Webhook format

The Webhook channel sends a JSON POST request with the header User-Agent: Ctadel-Notifier/1.0 and your custom headers:

{
  "finding_type": "cspm",
  "severity": "HIGH",
  "title": "CSPM: <RULE NAME>",
  "details": "Resource: <RESOURCE>, Category: <CATEGORY>",
  "resource_id": "<IDENTIFIER>",
  "rule_key": "<RULE KEY>",
  "project_id": "<PROJECT>",
  "count": 1,
  "timestamp": "2026-10-10T08:00:00Z"
}

With a signing secret, two headers are added: X-Ctadel-Timestamp (Unix timestamp) and X-Ctadel-Signature in the form t=<TIMESTAMP>,v1=<hex HMAC-SHA256 of "<TIMESTAMP>.<BODY>">. The timestamp is part of the signature, so the receiver can reject a replay.

Alert rules

Open "Settings", tab "Notifications", card "Alert Rules", then "Add Rule". Without a channel, the card shows: "First configure a channel in Integrations > Notifications, then add rules here."

Evaluation follows this order: when specific rules are listed, only their key counts, then the project; otherwise the event type, the minimum severity, the ticked types and the projects.

Event types

Only new findings are notified: a finding already known, reopened or resolved produces nothing. Messages are written in English.

A rule that must receive scan completions or assistant messages therefore has to tick the type and keep the minimum severity at "All severities" or LOW.

Emails

There is no email channel. Only two emails leave the instance outside authentication:

• The full scan summary, when the "Email when a full scan completes" switch of the "General" tab is on. It goes to every person holding the "Global Admin" role, in their language.
• The infrastructure alerts described below, which go to the Ctadel operator.

Deduplication and delivery

• The same event (alert rule, resource, rule key, type) is sent once per 5-minute window.
• Sends are paced. During a burst, a message that cannot be sent is dropped and will be sent again the next time the finding is reported.
• A temporary refusal (HTTP 429, 5xx error, timeout, connection refused) is retried a few times. A permanent refusal (another 4xx error, invalid configuration) drops the message, with a trace in the instance's technical logs.

Infrastructure alerts

The "System status" card of the "General" tab tracks the state of the instance's internal services and the heartbeat of every component. A component silent for more than 5 minutes turns "Down"; its return is reported too. Both transitions produce a system event.

These alerts are meant for the Ctadel operations team, which receives them by email and webhook on its own addresses. They are never emailed to the administrators of your instance. You receive them on your channels only when an alert rule ticks the system type, as the card says: "A component silent for more than 5 minutes alerts the Ctadel operations team automatically; recovery is notified too. Add the system type to a notification rule if you also want these events on your own channels."

Limitations

• No email channel for findings; emails are limited to the scan summary and to the operator alerts. The "Preferences" page points to these settings, but there is no personal notification.
• The cve type is listed although no event is emitted: a rule that ticks only this type receives nothing.
• Secrets found while scanning a pull request are not notified; only those on the default branch are.
• Nothing is sent when a finding is resolved or reopened, and there is no periodic digest of findings.
• Messages are in English whatever the language of the instance.
• Rules belong to the instance; there is no per-user notification.
• Destinations on a private network are refused; no option of the interface lifts this rule.
• No delivery log in the application: a failed send is only visible in the instance's technical logs.
• Deduplication does not survive a restart of the instance.
• The system, scan and agent events carry no project; the "Projects" filter does not apply to them.