Notifications & subscriptions¶

SLAtus sends notifications about component status changes, incidents, maintenance and SLA reports. Four independent channels are supported: e-mail, webhook, SMS and web push.

Who receives e-mail¶

The site setting subscription mode controls e-mail recipients (settings.subscriptionMode):

Mode	Recipients
`none`	No e-mail subscriptions. Public subscription is disabled.
`users`	All user accounts, regardless of role
`users_public`	All user accounts and all confirmed subscribers

Admin-managed subscribers (on /admin/subscribers) are treated as confirmed.

Public subscription (double opt-in)¶

Available only when the mode is users_public and an e-mail provider is configured. Otherwise the dialog says that e-mail subscriptions are disabled.

A visitor enters an e-mail address in the subscribe dialog on the status page, optionally with a name (at most 200 characters).
If the address is already confirmed, the dialog says it is already subscribed, and no e-mail is sent.
Otherwise a confirmation mail with a token link is sent (double_optin). This mail goes by e-mail only, to the given address, never over webhook, SMS or push.
The link opens a page with a confirm button. Only the button press confirms the address. Opening the link alone changes nothing.
The link is valid for 7 days. Expired or invalid links show a clear message. Nothing is confirmed.

Confirmed tokens are kept until the daily cleanup clears them after 30 days, so repeated clicks still produce the "already subscribed" message.

The server actions return errors of the public forms as codes (lib/validations/public-form-errors.ts). The forms show them in the configured language.

Unsubscribing¶

The unsubscribe page sends a confirmation mail with a token link, but only to confirmed addresses. The answer on the page is the same for every address. The second step is again a button press. Deletion happens only with a valid token; the link is valid for 7 days. Unknown and expired tokens are reported differently, and the page offers the form again.

Subscribers can request their stored data at /subscribe/my-data. The flow mirrors unsubscribing: request by e-mail, confirm through the link and button. The data export contains e-mail, name, source, verification and creation time, and can be downloaded as JSON. The token is valid for 7 days. The page only shows the data; deletion works through unsubscribing.

Rate limit on the public forms¶

Subscribing, requesting an unsubscribe link and requesting data access are throttled (allowPublicFormRequest in lib/auth/public-form-throttle.ts). There are two counters in auth_throttle:

Counter	Default	Lockout
Per client IP, across all three forms	10 requests in 60 minutes	60 minutes
Per address and form	1 request in 10 minutes	10 minutes
Shared counter `unknown`, when no client IP can be determined	100 requests in 60 minutes	60 minutes

Every request counts, not only failed ones. The last allowed request still goes through; after that, the counter is locked until the lockout ends.
A throttled request answers like a successful one ({ ok: true }), but no mail is sent. For a confirmed address, the "already subscribed" note is then missing as well.
The address counter does not store the address, but an HMAC-SHA-256 keyed with SESSION_SECRET.
The values can be changed with PUBLIC_FORM_RATELIMIT_* (see Deployment, migrations & CI). If the store fails, the forms continue without throttling.

Per-component control¶

Each component has the following settings, editable under Services → (service) in the Notifications card:

Send notifications for this service (notifications_enabled): a master switch. If all affected components are muted, nothing is sent on any channel.
Notify via (notify_mail_enabled, notify_sms_enabled, notify_webhook_enabled, notify_push_enabled): each channel can be blocked separately for a component.
Additional notification email address (notification_email): an extra recipient that receives mails for this component, if the mail channel is active for it. It is added as BCC and deduplicated.

Dispatches with an explicit recipient list, such as double opt-in mails, do not include the extra recipient.

Channels¶

Channel	Setup	Notes
E-mail	Settings → Mail/SMS/Push/Webhook, card Email-Setup (SMTP or Resend). Provider `none` disables e-mail.	Templates per event type are editable under Notifications, with placeholders such as `{{siteName}}`. A shared mail closing with an unsubscribe link is appended.
Webhook	Settings → Mail/SMS/Push/Webhook, card Webhooks. Admins only (`ROLES_CAN_MANAGE_NOTIFICATIONS`).	Target URL, generated secret (encrypted, can be regenerated), optional event filter, target type `generic`, `slack`, `teams` or `discord`. Signed with HMAC-SHA256 in the `X-SLAtus-Signature` header. 3 attempts with a 10-second timeout.
SMS	Settings → Mail/SMS/Push/Webhook, provider Twilio	Admin-managed recipients. No self-registration for visitors, on purpose, because of cost, abuse and privacy. Message is capped at 300 characters.
Web push	Settings → Mail/SMS/Push/Webhook, VAPID keys generated in the admin UI	Visitors opt in with the bell button in the header, on phones in a menu. The bell only appears once keys are generated. The VAPID subject must start with `mailto:` or `https:`.

Each event type has a template row with an enable flag per channel. A channel without an enabled row does not send. If the row for a new event type is missing, the worker creates it on its next start with all channels enabled (ensureNotificationTemplateRows). Only between the migration and the worker restart do you need to enable a new type by hand under Notifications.

Mail-only types (MAIL_ONLY_EVENT_TYPES, currently double_optin) are sent by e-mail only. Webhook, SMS and push skip them regardless of the flags. On the server, they can be set neither as an event filter of webhook, SMS or push nor as a channel flag.

Monitoring deliveries¶

/admin/notification-events lists the dispatched e-mail events with status pending, processing, sent or failed. Failed events offer Resend. If an event reached only some of its recipients, the list shows "x / y" recipients and the button reads Resend remaining. It only delivers to the remaining recipients.
/admin/notifications contains the templates and channel flags.
Webhook, SMS and push have their own delivery tables. Each webhook, SMS recipient and push subscription shows its last delivery status in the settings.