Build an alert with a clear outcome

1. Complete Set up storage if offered. This step enables no rule or destination.
2. Read the one-time server-setup panel. Destination setup requires PHP Sodium and a valid private alert encryption key. An administrator must preserve any existing key; replacing it can make encrypted records unreadable.
3. Add a labelled WordPress email, signed HTTPS webhook or Slack webhook destination. Choose an eligible WordPress recipient for email, or supply the appropriate secret URL for a webhook.
4. Review the minimized-facts consent, choose the destination's enabled state, and Save destination. Saving does not send a test.

1. Use the readable builder for a supported severity rule, including threshold, window, count, grouping, cooldown, severity and destination choices.
2. Choose Preview expression. It examines a bounded retained sample without saving a rule or sending a notification.
3. Review the result and the draft, then choose Save rule version. Check the confirmation for enabled or disabled state and whether replay was requested.
4. If needed, explicitly authorize Queue synthetic test on an enabled destination. Review Recent delivery history afterward.

The declarative source remains authoritative, especially for compound rules. New versions normally start with future sources; explicit replay can create notifications from retained sources.

A webhook signing secret is displayed once after saving. Store it privately. Editing a webhook requires its URL again, changes the secret and invalidates queued messages for the prior revision.

Accepted means the transport or mail subsystem reported acceptance. It does not prove receipt. A rule still needs an enabled, available destination; a successful configuration save is not an end-to-end delivery test.