mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-27 18:57:09 +00:00
feat(notifications): move Notification Routing to Skipper tier (#1145)
* feat(notifications): move Notification Routing to Skipper tier Notification routing is automation (route alerts to channels by rules), not enterprise compliance. Aligning the gate with Skipper makes the tier boundary read consistently with the rest of the automation surface (webhooks, auto-update, auto-heal, scheduled tasks). Backend: requireAdmiral -> requirePaid on the five /api/notification-routes endpoints. Dashboard configuration-status now exposes the routing-rules row to any paid tier. Frontend: settings registry tier flipped to skipper; the Admiral wrapper around NotificationRoutingSection is removed (the inner CapabilityGate stays, preserving forward-compat with older remote nodes). Tests: added a tier-enforcement describe block covering Skipper (200) and Community (403 PAID_REQUIRED on all five endpoints). Docs: refreshed alerts-notifications, licensing, overview, dashboard, troubleshooting, and reference/settings; cleaned one fence-spec line per Directive 31. * fix(notifications): address audit findings on tier-move PR Docs: rewrite three lines that survived the initial sweep. The dashboard "you do not see a locked placeholder" clause and the settings.mdx "hidden on Community and Skipper" phrase were Directive 31 fence-spec. The alerts-notifications troubleshooting note still said "an Admiral routing rule" and contradicted the tier move. Tests: the Community-negative cases on POST/PUT/DELETE/POST :id/test could not distinguish requirePaid from a stray requireAdmiral, because Community fails on the tier check before variant is read. Adding Skipper-positive coverage per endpoint locks the gate identity in. Replace the leaky mockReturnValueOnce with a per-test mockReturnValue plus an afterEach restore so spies cannot bleed across tests.
This commit is contained in:
Anso
@@ -1,9 +1,9 @@
|
||||
---
|
||||
title: Alerts & Notifications
|
||||
description: Threshold and event alerts for your fleet, dispatched to Discord, Slack, or any webhook, with per-stack rules and Admiral routing.
|
||||
description: Threshold and event alerts for your fleet, dispatched to Discord, Slack, or any webhook, with per-stack rules and Skipper routing.
|
||||
---
|
||||
|
||||
Sencho watches each node it manages for container crashes, host pressure, scheduled-task results, and update availability, then surfaces every signal in two places: the in-app notification bell at the top of the shell and one of three external channels you configure. This page covers everything from configuring channels to writing per-stack threshold rules, routing alerts to dedicated channels with Admiral routing rules, and tuning retention.
|
||||
Sencho watches each node it manages for container crashes, host pressure, scheduled-task results, and update availability, then surfaces every signal in two places: the in-app notification bell at the top of the shell and one of three external channels you configure. This page covers everything from configuring channels to writing per-stack threshold rules, routing alerts to dedicated channels with Skipper routing rules, and tuning retention.
|
||||
|
||||
<Frame>
|
||||
<img src="/images/alerts-notifications/notifications-settings.png" alt="Settings · Notifications panel showing the Discord, Slack, and Webhook tabs with the masthead breadcrumb, the CHANNELS 3/3 stat, the active Discord tab with its Enabled toggle on, the Webhook URL input, and the Test and Save actions." />
|
||||
@@ -51,7 +51,7 @@ Each dispatch is a single-shot HTTP POST with a 10-second `AbortSignal.timeout`.
|
||||
## Notification Routing
|
||||
|
||||
<Note>
|
||||
Notification Routing requires a **Sencho Admiral** license. Admin role is required to create, edit, or delete routes.
|
||||
Notification Routing requires a **Sencho Skipper or Admiral** license. Admin role is required to create, edit, or delete routes.
|
||||
</Note>
|
||||
|
||||
Routing lets you direct alerts that match specific criteria to dedicated channels. Production crashes can land in `#prod-incidents` on Slack while staging notifications go to a less urgent Discord channel, all without juggling per-channel webhook URLs across teams.
|
||||
@@ -392,7 +392,7 @@ Switching the active node tears down per-stack rule editors and reloads channel
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Notifications never arrive in Discord, Slack, or my webhook">
|
||||
Check three things in order. First, the channel toggle in **Settings · Notifications** must be on; the kicker on each tab reads `enabled` or `off`. Second, the URL must use HTTPS; the form rejects plain `http://` outright. Third, an Admiral routing rule with empty `Stacks`, `Labels`, and `Categories` matchers will intercept every alert and skip the global channels. Use the per-channel **Test** button to issue a one-shot dispatch and watch your endpoint for the literal message `🔌 Test Notification from Sencho!` Sencho records the failure reason in `notification_history.dispatch_error` when delivery throws, so a row that appears in the bell with no follow-up at the endpoint usually means a 4xx or timeout at the receiver.
|
||||
Check three things in order. First, the channel toggle in **Settings · Notifications** must be on; the kicker on each tab reads `enabled` or `off`. Second, the URL must use HTTPS; the form rejects plain `http://` outright. Third, a routing rule with empty `Stacks`, `Labels`, and `Categories` matchers will intercept every alert and skip the global channels. Use the per-channel **Test** button to issue a one-shot dispatch and watch your endpoint for the literal message `🔌 Test Notification from Sencho!` Sencho records the failure reason in `notification_history.dispatch_error` when delivery throws, so a row that appears in the bell with no follow-up at the endpoint usually means a 4xx or timeout at the receiver.
|
||||
</Accordion>
|
||||
<Accordion title="An alert rule never fires even when the threshold is breached">
|
||||
Three causes account for almost every case. First, the rule's **Duration** has not elapsed yet: the breach must persist for the full duration before the rule fires. Second, the rule is still in cooldown after a previous fire. Third, the panel's banner is not green: a remote-node banner means the rule was saved on a remote whose channels you may not have configured, and an amber `No notification channels configured` banner means the rule evaluates fine but Sencho has nowhere to send the alert. The evaluator runs on a 30-second tick, so expect up to 30 seconds of latency between the breach starting and the timer engaging.
|
||||
|
||||
@@ -89,7 +89,7 @@ The card is divided into four sections.
|
||||
|-----|---------------|
|
||||
| **Notification agents** | The list of enabled delivery agents from `Discord`, `Slack`, `Webhook`, joined by commas; reads `None` when no agent is enabled |
|
||||
| **Alert rules** | Total per-stack alert rules in effect, formatted `<n> rules` |
|
||||
| **Notification routing** (Admiral) | Number of enabled routing rules that direct categories to specific agents, formatted `<n> routes` |
|
||||
| **Notification routing** | Number of enabled routing rules that direct categories to specific agents, formatted `<n> routes` |
|
||||
|
||||
### Automation
|
||||
|
||||
@@ -118,7 +118,7 @@ The Automation block only renders on Skipper or Admiral.
|
||||
| **Alert thresholds** | The current host thresholds, formatted `CPU x% · RAM y% · Disk z%` |
|
||||
| **Crash detection** | `On` when global container-crash notifications are enabled, `Off` otherwise |
|
||||
|
||||
Click any row to jump directly to the settings section that manages it. Rows that require a higher tier than the active license are not rendered at all; you do not see a locked placeholder. The section headers (Notifications, Automation, Security, Backups & Thresholds) only render when at least one of their rows is visible.
|
||||
Click any row to jump directly to the settings section that manages it. Rows that require a higher tier than the active license are not rendered. The section headers (Notifications, Automation, Security, Backups & Thresholds) only render when at least one of their rows is visible.
|
||||
|
||||
The data refreshes automatically every 60 seconds and immediately on any container start/stop/restart event broadcast over the live notification stream, so the card stays in lockstep with what the rest of the UI shows.
|
||||
|
||||
|
||||
@@ -41,6 +41,7 @@ For larger deployments, an **Enterprise** tier is available with custom pricing,
|
||||
|
||||
- Fleet View with search, sort, filter, and node-card drill-down
|
||||
- Webhooks (incoming, to trigger deploys from CI/CD)
|
||||
- Notification routing (per-stack and per-category rules to Discord, Slack, or any webhook)
|
||||
- Atomic deployments with rollback
|
||||
- Auto-update policies for stack images
|
||||
- Auto-heal policies
|
||||
@@ -61,7 +62,6 @@ For larger deployments, an **Enterprise** tier is available with custom pricing,
|
||||
- Host Console (a browser-based terminal on the Sencho host)
|
||||
- API tokens for CI/CD scripts
|
||||
- Private and custom registry credentials
|
||||
- Notification routing
|
||||
- Sencho Mesh (cross-node container networking)
|
||||
- Sencho Cloud Backup
|
||||
- Auto-update of the managed Trivy binary
|
||||
|
||||
@@ -83,7 +83,7 @@ Configure threshold-based alerts (CPU, memory, network, restart count) per stack
|
||||
|
||||
### Notification routing
|
||||
|
||||
Route alerts to specific channels with per-stack routing rules. Send production alerts to a critical Slack channel while routing dev stack alerts to a less urgent Discord channel. Admiral only. [Learn more →](/features/alerts-notifications#notification-routing)
|
||||
Route alerts to specific channels with per-stack routing rules. Send production alerts to a critical Slack channel while routing dev stack alerts to a less urgent Discord channel. [Learn more →](/features/alerts-notifications#notification-routing)
|
||||
|
||||
### Audit log
|
||||
|
||||
|
||||
Reference in New Issue
Block a user