Alerting & SIEM Integration

Configure notification rules to route LinuxGuard signals to your alerting and SIEM destinations.

Prerequisites

• Access to the LinuxGuard console with administrator role

• At least one delivery channel configured: a webhook endpoint, a syslog destination, or a Splunk HEC destination

Create a Notification Rule

1. Navigate to Settings in the LinuxGuard console and open the Notification Rules section.

2. Select New Rule and provide a descriptive Name for the rule.

3. Set the Trigger Type to signal_created. This is the standard trigger for signal-based alerting and SIEM forwarding.

4. Under Channels, select one or more delivery channels to receive signals when this rule fires. A rule can deliver to multiple channels simultaneously — for example, a webhook and a syslog destination at the same time.

5. Optionally configure Filter Conditions to limit which signals the rule matches. See Filter Conditions below for the full reference. Leave conditions empty if you want the rule to match every signal (useful for a catch-all SIEM forwarding rule).

6. Optionally configure Throttle to limit delivery volume. See Throttle below.

7. Optionally configure Quiet Hours to suppress deliveries during off-hours windows. See Quiet Hours below.

8. Save the rule. The rule becomes active immediately for new signals.

Filter Conditions

Conditions use AND logic: all configured conditions must match a signal for the rule to fire. A rule with no conditions configured matches every signal, which is useful for a catch-all forwarding rule that ingests all signals into a SIEM.

Condition	What it filters	Allowed values	Example
severity	Minimum signal severity	info, low, medium, high, critical	medium — matches medium, high, and critical signals
categories	Signal category	Signal category name	privilege_escalation
environments	Agent environment tag	Environment name string	production
tags	Agent tag	Tag name string	web-tier
identity_types	Identity type of the actor	user, service_account	user

Note: The severity condition matches the specified level and all higher severities. Configuring severity: medium will match medium, high, and critical signals — it does not filter for medium-severity signals only.

Throttle

Throttle limits how many signals a rule delivers within a time window. Use throttle to prevent high-volume incident events from overwhelming a receiving system or generating too many notifications.

Two throttle patterns are available. Use one or the other — do not combine max_per_hour with max_per_period.

Pattern 1 — per-hour limit. Caps deliveries to a fixed number per hour:

{ "max_per_hour": 10 }

Pattern 2 — flexible period. Caps deliveries within a custom period window:

{ "max_per_period": 5, "period_minutes": 30 }

Throttle applies per rule per channel destination. If a rule delivers to two channels, each channel has its own throttle counter.

Quiet Hours

Quiet hours define a daily window during which signal delivery is suppressed for this rule. Configure quiet hours to avoid non-urgent notifications during off-hours.

{
  "start": "22:00",
  "end": "06:00",
  "critical_bypass": true
}

Note: Quiet hours start and end times are in UTC. Overnight ranges (where start is later than end) are supported — the example above suppresses from 22:00 UTC to 06:00 UTC. With critical_bypass: true, critical-severity signals are delivered even during the quiet window.

---

Related: Alerting & SIEM Integration | Webhook Integration | Syslog Forwarding | Splunk HEC Integration