Security Alert Configuration

Security alert configuration page at /settings/security-alerts where administrators define which security events generate alerts, set their severity, and enable or disable individual rules.

​

Overview

The Security Alert Configuration page provides a CRUD interface for the pf_security_alert_configs table. Each config record specifies an alert_name, an event_type (one of: failed_login, permission_violation, suspicious_activity, account_lockout, mfa_failure), a severity (one of: info, warning, error, critical), and an is_active toggle. Admins can create, edit, and delete configurations via dialogs. Delete requires confirmation. The page is gated by pf.security_alerts.manage.

​

Who it’s for

Required permission: pf.security_alerts.manage

​

Before you start

• You must hold the pf.security_alerts.manage permission.
• Determine which event types and severity thresholds are relevant to your organization’s security posture.

​

Steps

1. Navigate to /settings/security-alerts.
2. Review existing alert configurations in the table.
3. To add a new alert rule, click New Alert and complete the form.
4. To edit an existing rule, click its edit icon.
5. To enable or disable a rule, toggle the Active switch on the rule.
6. To remove a rule, click its delete icon and confirm.

​

Key concepts

event_type — The security event category that triggers this alert. Available types: failed_login, permission_violation, suspicious_activity, account_lockout, mfa_failure. severity — The urgency level assigned to the alert: info, warning, error, or critical. is_active — Whether the alert rule is currently evaluating incoming events.

​

Built-in default rules

Every organization starts with a set of platform-managed alert rules that fire immediately to in-app notifications when a matching event is recorded. These rules appear in the list but do not belong to your organization, so you cannot edit or delete them — you can add organization-specific rules alongside them. High-volume event types like failed_login and rate_limit_exceeded are intentionally excluded from the defaults. Add an organization-scoped rule with a tighter severity filter if you want to alert on them.

​

How delivery works

When a security event is recorded for your organization, every active rule whose event_type and severity filter matches the event triggers a notification. Delivery to the configured channels (currently in-app) happens automatically — you do not need to configure a downstream webhook or notification job.

​

Related

Documentation sources

• src/routes/platform.tsx
• src/platform/security/pages/SecurityAlertConfigPage.tsx
• src/platform/security/hooks/useSecurityAlertConfigList.ts