Documentation Index
Fetch the complete documentation index at: https://mintlify.com/DevDonzo/warden/llms.txt
Use this file to discover all available pages before exploring further.
Warden can push a structured notification to your team’s communication channels at the end of every scan run. Notifications are posture-driven: a critical posture fires an error-severity message, an elevated posture fires a warning, and anything better sends a success signal. This lets your alerting rules in Slack or PagerDuty key off severity rather than requiring you to parse log output.
Notifications are opt-in. The notifications.enabled field defaults to false in every new .wardenrc.json. No messages are sent until you explicitly set "enabled": true.
When Notifications Fire
The NotificationService is called by the orchestrator at the end of every scan run that produces a result. It maps the scan posture to a NotificationSeverity value:
| Posture | Notification severity |
|---|
critical | error |
elevated | warning |
guarded or stable | success |
The NotificationPayload Shape
Every channel receives the same normalized payload:
interface NotificationPayload {
title: string; // e.g. "Warden Scan Completed"
message: string; // Remediation plan summary
severity: 'info' | 'warning' | 'error' | 'success';
details?: {
repository?: string; // Target path or repo URL
vulnerabilities?: number;
fixed?: number;
prUrl?: string; // URL of the fix PR, if created
};
}
details fields as inline attachment fields. The email channel renders them as a plain-text or HTML table.
Slack
Add a notifications.slack object to .wardenrc.json:
{
"notifications": {
"enabled": true,
"slack": {
"webhook": "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXX",
"channel": "#security-alerts"
}
}
}
| Field | Required | Description |
|---|
slack.webhook | Yes | Slack Incoming Webhook URL — create one at api.slack.com/messaging/webhooks |
slack.channel | No | Channel override (e.g. #security-alerts). If omitted, the webhook’s default channel is used |
#ef4444 red for error, #f59e0b amber for warning, #10b981 green for success), the scan title, the remediation summary, and inline fields for repository, vulnerability count, fixes applied, and PR URL.
Discord
Add a notifications.discord object:
{
"notifications": {
"enabled": true,
"discord": {
"webhook": "https://discord.com/api/webhooks/000000000000000000/xxxxxxxxxxxx"
}
}
}
| Field | Required | Description |
|---|
discord.webhook | Yes | Discord Webhook URL — create one under Server Settings → Integrations → Webhooks |
Email via Resend
Warden’s built-in email provider is Resend. Set up an API key in the Resend dashboard and export it as an environment variable:
export RESEND_API_KEY=re_xxxxxxxxxxxxxxxxxxxx
{
"notifications": {
"enabled": true,
"email": {
"to": ["security@example.com", "oncall@example.com"],
"from": "Warden <warden@yourdomain.com>",
"provider": "resend",
"apiKeyEnv": "RESEND_API_KEY",
"subjectPrefix": "MyApp"
}
}
}
| Field | Default | Description |
|---|
email.to | — | Array of recipient email addresses |
email.from | — | Sender address (must be a verified domain in Resend) |
email.provider | "resend" | Email provider — "resend" is the only built-in provider |
email.apiKeyEnv | "RESEND_API_KEY" | Name of the environment variable holding the Resend API key |
email.subjectPrefix | "Warden" | Prefix used in the email subject line, e.g. [MyApp] ✅ Warden Scan Completed |
apiKeyEnv is set but the environment variable is not present at runtime, Warden skips email silently (with a debug log) rather than failing the scan.
Email via Generic Webhook
For teams that route email through Zapier, Make, an AWS SES Lambda, or an internal notification service, set email.webhook instead of configuring a Resend API key:
{
"notifications": {
"enabled": true,
"email": {
"to": ["security@example.com"],
"from": "Warden <warden@yourdomain.com>",
"webhook": "https://hooks.zapier.com/hooks/catch/0000000/xxxxxxx/",
"subjectPrefix": "MyApp"
}
}
}
email.webhook is set, Warden posts a JSON body to that URL via POST:
{
"to": ["security@example.com"],
"from": "Warden <warden@yourdomain.com>",
"subject": "[MyApp] ⚠️ Warden Scan Completed",
"text": "3 high-severity findings — 2 are auto-fixable via dependency upgrades.\n\nRepository: /home/runner/work/myapp\nVulnerabilities Found: 14\nFixed: 2\nPull Request: https://github.com/org/myapp/pull/47",
"html": "<p>3 high-severity findings...</p><table>...</table>",
"severity": "warning",
"details": {
"repository": "/home/runner/work/myapp",
"vulnerabilities": 14,
"fixed": 2,
"prUrl": "https://github.com/org/myapp/pull/47"
}
}
Use email.webhook when you need custom routing logic — for example, paging on-call only when severity is "error", or sending to different distribution lists based on the repository name. Your webhook handler has full access to the severity and details fields to implement any routing rule.
Complete Notifications Configuration
{
"notifications": {
"enabled": true,
"slack": {
"webhook": "https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXX",
"channel": "#security-alerts"
},
"discord": {
"webhook": "https://discord.com/api/webhooks/000000000000000000/xxxxxxxxxxxx"
},
"email": {
"to": ["security@example.com"],
"from": "Warden <warden@yourdomain.com>",
"provider": "resend",
"apiKeyEnv": "RESEND_API_KEY",
"subjectPrefix": "MyApp"
}
}
}
Promise.all, so a failure in one channel (e.g., an expired Slack webhook) does not block the others. Failures are logged as errors but do not cause the scan to exit with a non-zero code.