#Notifications

B3.14+B3.15 now built/pushed by Pair2 (2026-10-10). Channels have no saved-count cap, publicHTTPS443 webhook destinations, masked retained credentials and asynchronous tests. Queued is not sent; locally recorded means no email delivered. Current channel API/screens. IP-added account-security notices to saved channels conflict with Bhavik's server/app-only rule; do not treat routing as approved. Phase11 routing/attachments remain future work.

#Requirements (V8 Phase 3) V8 requirement

#	Feature	Rules
3.14	In-app notifications	Paginated list, unread count, mark one / all as read
3.15	Notification channels	Email, Telegram, Pushover, Slack, Discord, Webhook. Add / edit / delete + send test. Discord is set up with a Discord webhook URL (like Slack). Webhook takes public HTTPS URL on port443 and Central POSTs the notification (title + message) there as JSON, like V7 V8 requirement 2026-10-03
3.17	Server alerts	Central calls the OSS API to get server alerts, shows them and sends them to the user's channels. Built with the Servers phase
3.5	Email preferences	On/off: account updates, credentials, informative emails

#V7 reference V7 only

notifications (Laravel database notifications): GET /notifications/unread, GET /notifications/mark-as-read.
notification_channels (per user): type, label, bot_token, group_id, email, webhook_url. Endpoints: resource + send-test-notification. V7 already had Discord and Webhook types (both use webhook_url), which is why the backend added them to V8 on 2026-10-03 — migrated channels keep working.
Per-server channel links: GET/POST /servers/{server}/notification-channels, DELETE …/{id}.
Server alerts were produced by V7's own monitoring jobs (execute:server-monitor, execute:service-monitoring, disk alerts from InsightHub webhook).

Note

Resolved 2026-10-05 — D-17 is answered, and the answer is option (a). This page used to warn that OSS has no alerts API (checked at e60c6bd7), so requirement 3.17 had no endpoint to call. Backend Phase 11 settles it: Central asks each server's OSS panel — OSS does not push. Two separate mechanisms (reworked by the backend at 10:19): Central reports the actions it performed itself right after OSS answers, following long ones with a background job (11.11); and scheduled jobs poll existing OSS APIs for what the server does on its own — backups, SSL, auto-deploys, live metrics, services and health (11.12), with how often set by the admin. Alerts compare live metrics against limits the user sets per server (11.13, V7 defaults, two of them based on the core count) and include the top processes; each alert is sent once until fixed, then a "back to normal" (11.14). Two consequences for the screens: an event is only as fresh as its own schedule, and work done directly in the OSS panel is deliberately not notified — so the feed is not a full history of a server.

#In-app UX

Bell in the top bar with an unread badge. A popover lists the latest 10, with "Mark all as read" and "View all" (/notifications).
Each item: icon by type, translated title/body (the backend sends a type + params, not English text Assumption), time, link to the resource.
Real-time: V8 Phase 1 excludes broadcasting V8 requirement, so poll the unread count (e.g. every 60 s while visible) until broadcasting exists.

#Notification groups — published by the backend

Phase 11 (2026-10-05) replaces the proposal this page used to carry. V8 requirement There are ten fixed groups — six at server level (Alerts, Backups, Apps & deploys, SSL & domains, Databases, Server changes) and four at account level (Security, Billing, Plan, Organization, the first three required). The events inside each group come from the backend's event list (11.5), so a later phase adds events without new groups and without a frontend change. The full list, with everything each group covers, is on FE: Notifications & mail.

How the user controls them (11.7): channels are attached per server, each with the six server groups ticked — all on by default, as in V7 — and the four account groups are chosen once in Account → Notification settings. That account-level reach is new in V8 (11.8); V7 sent only server events to channels.

The earlier frontend proposal on this page (a hand-written list of server.offline, subscription.expiring, wallet.low_balance and so on) is dropped — every one of those cases falls inside a published group, so there is nothing left for the frontend to invent.