Notifications
Notifications pillar — notification rules, suppressions, and rule edit/new flows in the LinuxGuard console.
The Notifications pillar manages how LinuxGuard events become outbound notifications. It is where operators define the rules that match events (signals, drift, compliance findings, efficiency findings), set the routing targets (which integration receives the notification), apply suppressions (which events explicitly do not produce notifications), and review the per-rule history of notifications produced.
Note: The LinuxGuard Console is the canonical reference for screen-by-screen layout. This page describes the conceptual scope and integration points.
Notifications is the console-side companion to the file-based respond/notification-rules.md configuration surface. Both surfaces drive the same notification engine — a rule defined in the console and a rule defined in the agent-level notification-rules.yaml file are processed by the same pipeline. The distinction is operator-facing: the console surface is for tenant-wide rules managed by security / operations leads through the UI; the agent-side file surface is for per-host rule overrides managed by configuration management. Most tenants use the console surface as the primary; agent-side rules exist for specialized per-host policy.
Notification rules
A notification rule has four parts: a match expression, a scope, an action, and operational settings (cooldown, deduplication, throttle).
The match expression selects which events the rule applies to. It can match on:
Event source
Signals, Config Drift, Compliance, Efficiency, Audit, Baselines
Event category
Within source — e.g., for Signals: MITRE technique, signal type
Severity
Critical, High, Medium, Low
Identity attribute
Specific user, group membership, NHI tier
Server attribute
Environment, tag, hostname pattern
Time of day / day of week
Business hours, after hours, weekends
Match expressions support AND / OR composition. A typical rule like "Critical signals on production servers during after-hours" is expressed as (severity = Critical) AND (server.environment = production) AND (time = after-hours).
The scope narrows the rule's reach to a subset of the fleet. Scope is independent of the match expression: a match on "Critical signals" can be scoped to "only production servers," to "only the webapp-prod tag," to "all servers," or to "a specific server set." Scope is the deployment lever that lets the same rule pattern roll out gradually (start scope-limited, expand as the rule proves reliable).
The action is the routing target. Actions reference Integration entries (see Integrations) — a notification rule with action Slack:security-alerts posts to the Slack integration entry named security-alerts. A single rule can have multiple actions; a rule firing produces one notification per action.
Operational settings:
Cooldown
Minimum time between successive notifications from this rule for the same source event
Deduplication
Identical events within the deduplication window collapse into a single notification (with occurrence count)
Throttle
Maximum notifications per period for this rule; excess events queue or drop per the rule's overflow policy
Quiet hours
Time windows during which the rule does not fire
Operational settings are why notification rules feel reliable in production. Without cooldown / dedup / throttle, a single event source firing at high volume would saturate the integration target (and the on-call rotation). With them, the same rule produces an actionable notification stream regardless of underlying event volume.
Suppressions
Suppressions are documented decisions to not produce notifications for specific events. They are separate from notification rules: a suppression does not match-and-route; it match-and-silences.
Per-suppression fields:
Match expression
Same vocabulary as notification rules — which events are suppressed
Scope
Where the suppression is in effect
Reason
Free-text justification (required)
Approver
Identity that approved the suppression
Effective date
When the suppression begins
Expiration date
When the suppression auto-expires (strongly recommended)
Suppressions in Notifications are operational suppressions — "don't bother the on-call with this category of event for this maintenance window." They are distinct from policy-level suppressions in Zero Trust Expansion (which document that an event category is out of policy scope) and from compliance suppressions in Compliance Expansion (which document that a control is out of audit scope), though the same vocabulary is used everywhere.
Suppressions are first-class audit evidence. Every suppression appears in the tenant audit log with creator, approver, scope, and expiration. A suppression that has been in effect for an extended period without expiration is a yellow flag — it suggests the suppression has become permanent in practice and should either be expired (the condition has been resolved) or formalized as a policy-level decision.
Rule edit flow
Editing an existing rule walks the operator through:
Inspect current state — the rule's match expression, scope, actions, and operational settings as currently in force.
Modify — change any of the above. The console highlights diffs from the current state as the edit proceeds.
Preview — the console shows a sample of recent events the modified rule would have matched (over a configurable look-back window, typically the last 24 hours). This is the load-bearing safety step: the operator can see whether the modified rule would have fired on too few events (rule is too narrow) or too many (rule is too broad).
Save — the rule is persisted with the editing identity and timestamp. The new version takes effect from save time.
Edits do not affect historical notifications. A rule modified after an event fired does not retroactively suppress or re-route the notification that already went out. The rule edit log preserves prior versions; the operator can diff a current rule against any historical version.
Rule new flow
Creating a new rule walks the operator through:
Pick the rule template (optional) — the console offers templates for common rule patterns (e.g., "Critical signal on production server," "Compliance finding for in-scope framework," "Sudo execution outside business hours"). Templates are starting points; every field is editable.
Define the match expression — using the match-field vocabulary above. The console offers an expression builder with autocompletion over event sources, categories, and identity / server attributes.
Set scope — pick the scope by environment, tag, hostname pattern, or explicit server set.
Set action(s) — pick one or more Integration entries as routing targets.
Configure operational settings — cooldown, deduplication, throttle, quiet hours.
Preview — same preview surface as the edit flow: which recent events would the new rule have matched?
Activate or stage — stage the rule (configured but not firing — events that would have matched are visible in a "would have fired" view for review) or activate it (rule fires from creation forward).
Staging is a quiet rollout mechanism. A new rule that is staged for a week before activation gives the operator a real history of "would the rule have fired correctly?" before any real notifications go out. Most teams adopt the pattern of stage-first / activate-after-review for any rule with broad scope.
Data sources
Notifications is fed by:
Events from across the LinuxGuard surface (signals, drift, compliance findings, efficiency findings, audit events, baseline deviations)
Operator-defined rule and suppression configurations
Integration entries (see Integrations) — the routing targets that actions reference
The notification engine evaluates every event against every active rule, applies operational settings (cooldown, dedup, throttle), checks suppressions, and dispatches matching events to the action's integration. Delivery outcomes are tracked in Integrations → Deliveries.
Module gating
Notifications is available across tiers — every tenant has some notification surface. Subscription gating documented in console: the number of active rules per tenant, the operational settings available (cooldown granularity, throttle precision), and the depth of rule history retention may vary by tier. Per-tenant tier configuration documents the exact gating.
Cross-references
Related CLI commands:
config(agent-side notification-related settings)Related Concepts: Integrations (notification actions reference Integration entries), Zero Trust Expansion (policy-level suppressions are a higher tier of decision than operational suppressions), Compliance Expansion (compliance suppressions are framework-scoped)
Related How-to: Notification Rules (agent-side rule file surface), Respond (the integration target reference docs)
Related: Console | Integrations | Respond | Alerting & SIEM Integration | Glossary
Last updated
Was this helpful?