Alerts and notifications

The gateway and the control plane turn what they see into events: blocked and flagged requests (detection.blocked, detection.flagged), upstream failures, failed logins and 2FA lockouts, and changes to roles, SSO, policies and upstreams. Alert rules, kept per organization, match events and notify people:

• Channels: Telegram, Slack, Microsoft Teams, email (SMTP), signed webhooks (HMAC, for a SIEM or your own service), A2A agents (for example a SOC agent), and the bell in the admin UI.
• Rules: event types plus an optional condition in the policy text syntax, for example attrs.score >= 0.95 && "jailbreak" in attrs.categories; a threshold in a time window (5 blocks in 5 minutes), throttling, grouping by project or category, quiet hours and auto-resolve.
• Recipients: users, groups or roles. Each person links their own Telegram, Slack or email and picks a minimum severity.
• Delivery: an outbox with retries (2 s up to 30 min, 6 attempts), Retry-After honoured, and a delivery log in the UI. Channel secrets stay in environment variables named by the channel, never in the database, and never appear in error text.
• Off the request path: events are written after the response is sent. A full buffer drops events (guardspec_events_dropped_total) instead of slowing requests down.

To set it up, configure the SMTP_*, TELEGRAM_*, SLACK_* and ALERTS_* variables, then use the Alerts pages of the admin UI (the bell icon in the sidebar): rules, channels, groups, alert history and the delivery log. docs/alerts.md has the event types, the rule fields, the setup of each channel, webhook signature verification and the metrics.

Source: README.md#alerts-and-notifications @ ca69dad29f02