Alerts

Alert delivery is configured per organization under Settings → Features. It complements metrics and logs; it does not make the control plane a full monitoring system.

1. Open Settings → Features.
2. Confirm Alert delivery is enabled.
3. Under Alert destinations, select Manage.

Turning the feature off stops new delivery attempts. It does not remove destination definitions or erase external notifications already sent.

In Alert destinations:

1. Enter Name.
2. Choose Destination type: Generic webhook, Slack, Microsoft Teams, PagerDuty, Opsgenie, Discord, Google Chat, or Email.
3. Enter the HTTPS endpoint or provider-specific destination.
4. Choose Minimum severity: Info and above, Warning and above, or Critical only.
5. Set Cooldown seconds to control repeated delivery.
6. Leave Allow private-network destination off unless the control-plane host is intentionally allowed to reach that private address.
7. Select the event types.
8. Select Add destination.

Current agent event choices include offline, denial spike, access expiring, rotation failed, and configuration drift. Subscribe only the team that can act on each event.

Destination credentials are write-only. Never put a webhook token in a screenshot or documentation example. Prefer a dedicated provider credential with the narrowest scope and rotate it after any suspected disclosure.

Allowing a private-network destination expands where the control plane may send requests. Use an exact trusted endpoint, provider firewall rules, and a dedicated receiver; do not use it as a generic URL tester.

After adding a destination:

1. Confirm the destination shows active.
2. Generate or use an approved test event where the provider supports it.
3. Check Recent alert deliveries for outcome and timestamp.
4. Verify the external destination received one notification.
5. Confirm cooldown behavior for repeats.

The console intentionally does not display payload secrets or destination credentials in delivery history. No delivery attempts means no qualifying event has been sent; it is not proof that the destination works.

Check in order:

1. Alert delivery is enabled.
2. Destination is active and subscribed to that event.
3. Event severity meets the threshold.
4. Cooldown is not suppressing the repeat.
5. Control-plane DNS/HTTPS can reach the provider.
6. Provider credential and endpoint are still valid.
7. Private-address protection is not correctly refusing an unsafe endpoint.

Correlate the event with Access events and audit and bounded API logs. Do not weaken the destination policy merely to make a test green.