Alerts
Real-time notifications for vault events via email and webhooks.
Alerts notify you when specific events happen in your vault. Two delivery channels are available: email notifications sent to your account email, and webhooks that POST signed JSON payloads to your own HTTP endpoints.
Both channels use the same underlying event system. Every alertable action has a category and a severity level. You choose which actions trigger notifications on each channel independently.
Channels
| Channel | Delivery | Plan requirement |
|---|---|---|
| Sends a formatted email to your account email address | Paid plan | |
| Webhooks | POSTs a signed JSON payload to your HTTPS endpoint | Paid plan |
Email alerts and webhooks are configured separately. Enabling an action for email does not enable it for webhooks, and vice versa.
Event Categories
Actions are grouped into twelve categories. The category filter on the Alerts page lets you narrow the action list to one category at a time. Every action's full severity is in the audit log reference.
| Category | What it covers |
|---|---|
| Secrets | Secret CRUD, reads (granted and denied), rotation, version changes, schedule changes, soft delete and hard delete, restore from trash, TTL-driven destruction, export, access-policy CRUD, policy binds and unbinds, lease lifecycle, managed-secret sync configuration, agent connectivity, canary arming and triggers. |
| Machines | Machine registration, approval, denial, revocation, enable/disable, rename, expire, purge. Provisioning and provision-bundle downloads. CI template renders. Enrollment-token lifecycle. Temporary-machine bootstrap tokens, registration, guardrail updates, lifetime extensions, expiry, and policy blocks. |
| Projects | Project create, update, delete, freeze, unfreeze. Adding and removing machines to or from a project. |
| Authentication | Login (success and failure), logout, OAuth sign-in, OAuth link and unlink, registration, password changes including set, remove, reset, and reset-request, 2FA setup and enable/disable, recovery code use, passkey register/login/rename/revoke/failed plus signature-counter anomalies and recovery flows, refresh-token replay detection, account revocation, vault destruction. |
| Teams | Vault invites (sent, accepted, declined, cancelled), team member joined, left, removed, permission changes, project-level access revocation. |
| Sessions | Single-session revocation and full-account session revocation. |
| AI Agents | AI-agent bootstrap-token creation, registration, approval, denial, enable/disable, revocation, rename, scope and project-allowlist updates. |
| Billing | Subscription lifecycle (initiated, activated, cancel requested, cancelled, past due, paused), payment failures, payment-action-required prompts. |
| Webhooks | Webhook endpoint create, update, delete, and test deliveries. |
| IP Allowlist | Adding and removing CIDR entries, enabling and disabling the allowlist itself. |
| Integrations | Third-party integration connect and disconnect events (Supabase). |
| Temporary Secrets | Creation of one-time share links, recipient views, and failed view attempts (wrong passphrase, destroyed). |
Severity Levels
Every action has a fixed severity level:
| Severity | Meaning | Examples |
|---|---|---|
| Critical | Active compromise indicator, irreversible destruction | canary_triggered, refresh_token_replay, webauthn_counter_anomaly, vault_destroyed, secret_destroyed, project_delete, 2fa_disable, account_revoked, ip_allowlist_disable |
| High | Significant security change, trust boundary expansion, exfil vector | machine_register, machine_revoke, secret_delete, secret_hard_delete, secret_export, secret_read_denied, permission_grant, password_change, ai_agent_register, webauthn_register, oauth_link |
| Medium | Legitimate trust or access change | machine_approve, team_permission_update, team_invite, ip_allowlist_add, access_policy_create, secret_policy_bind, subscription_past_due, payment_failed, temp_machine_extend |
| Low | Routine administrative change | bootstrap_token_create, machine_purge, webauthn_rename, subscription_initiated, webhook_create, temporary_secret_create |
| Info | Normal operation, automated action, routine read | secret_read, secret_create, secret_rotate, login_success, ci_template_render, lease_created, webhook_test |
The Alerts page also offers a severity-level shortcut: a one-click "enable all High and Critical" button toggles every action at those severities on at once across every category.
How Alerts Fire
When an auditable action occurs, the backend writes to the audit log and then calls the alert dispatcher. The dispatcher:
- Sends the event to the webhook dispatcher, which delivers to all matching webhooks for the user (independent of email preferences).
- Checks if the user has an email alert enabled for that action, and sends the email if so.
Both channels run asynchronously and never block the operation that triggered them.