# 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](#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](#throttle) below.
7. Optionally configure **Quiet Hours** to suppress deliveries during off-hours windows. See [Quiet Hours](#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:

```json
{ "max_per_hour": 10 }
```

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

```json
{ "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.

```json
{
  "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](/explanation/explanation/alerting.md) | [Webhook Integration](/how-to-guides/how-to/configure-notification-rules/webhook-integration.md) | [Syslog Forwarding](/how-to-guides/how-to/configure-notification-rules/syslog-forwarding.md) | [Splunk HEC Integration](/how-to-guides/how-to/configure-notification-rules/splunk-hec-integration.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.linuxguard.io/how-to-guides/how-to/configure-notification-rules.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.