Creating Alert Rules

WhiteOwl provides a flexible alerting engine that monitors your network for threshold breaches, traffic anomalies, and holistic health issues. Click + Create Alert Rule on the Alert Management page to open the alert builder.

Select Alert Type

The first step is choosing one of four alert categories. Each provides a different approach to monitoring:

Type	Description
SNMP Alert	Pre-built templates for infrastructure health — CPU, memory, interface utilization, errors, and flapping. Fastest way to set up device-level monitoring.
Flow Alert	Pre-built templates for traffic and security — country-based anomalies, DDoS detection, traffic volume spikes, TCP retransmits, and latency.
AI Analysis	Holistic, AI-powered network review that runs periodically (every 6–24 hours). Analyzes all data sources like a senior NOC engineer reviewing the health of your infrastructure.
Custom Alert	Build from scratch with full control over metric source, thresholds, filters, and evaluation settings.

---

SNMP Alert Templates

Selecting SNMP Alert presents six pre-built templates with sensible default thresholds. Click a template to create the rule instantly, or customize it before saving.

Template	Description	Default Threshold
High CPU Usage	Alert when any device CPU exceeds threshold.	> 75%
High Memory Usage	Alert when any device memory exceeds threshold.	> 65%
High Interface Utilization	Alert when any interface utilization exceeds threshold.	> 60%
Interface Flapping	Alert when interface status changes frequently (up/down cycles).	>= 3 cycles
Interface Errors	Alert when interface error rate exceeds threshold.	> 100
Interface Packet Loss	Alert when interface discard rate indicates packet loss.	> 50

Each template creates a static threshold alert preconfigured with the appropriate metric source (SNMP), metric name, operator, and threshold value. You can modify any of these settings before clicking Create Rule.

---

Flow Alert Templates

Selecting Flow Alert presents seven pre-built templates focused on traffic analysis and security detection. These templates use either baseline deviation or static threshold depending on the use case.

Template	Description	Default	Type
High Inbound Country Traffic	Alert when traffic from a country exceeds baseline.	Baseline deviation: 300%	Baseline
Many Sources to One Destination	Alert when an unusual number of sources target a single destination (potential DDoS).	Baseline deviation: 500%	Baseline
TCP SYN Spike	Alert when TCP SYN packets exceed baseline (potential SYN flood).	Baseline deviation: 400%	Baseline
High Traffic Volume (Bps)	Alert when overall bits per second exceeds baseline.	Baseline deviation: 200%	Baseline
High Traffic Volume (PPS)	Alert when overall packets per second exceeds baseline.	Baseline deviation: 200%	Baseline
High TCP Retransmits	Alert when TCP retransmit rate indicates network issues.	> 5%	Static
High RTT Latency	Alert when average round-trip time exceeds threshold.	> 100 ms	Static

---

AI Analysis Templates

Selecting AI Analysis provides holistic, AI-powered network reviews. Unlike threshold-based alerts, AI Analysis runs periodically (every 6–24 hours) and examines all data sources together — SNMP metrics, flow data, synthetic test results, and device health — to identify issues, anomalies, and trends that individual threshold alerts might miss.

How AI Analysis Works

AI Analysis queries data across all monitoring sources and sends a comprehensive summary to an AI model with a domain-specific prompt. The AI acts like a senior NOC engineer reviewing the network, identifying patterns and correlations across multiple data points. Results are delivered as alert notifications with detailed narrative findings.

Template	Description	Recommended Interval
Morning Network Health Check	Comprehensive morning review — overnight issues, current health, capacity concerns, unusual patterns, and action items for the day shift.	Every 6 hours
Midday Performance Review	Mid-day check during peak usage hours — bottlenecks, degradation vs. morning, top consumers, latency, and afternoon predictions.	Every 6 hours
End of Day Summary	Daily summary and overnight preparation — day's events, open issues, trend analysis, anomalies, overnight watch items, and upcoming maintenance.	Every 24 hours
Security Posture Review	Review traffic patterns for security anomalies — unexpected source countries/ASNs, port scanning, data exfiltration, suspicious connection patterns, failed connections, and new high-volume IPs.	Every 12 hours
Capacity Planning Analysis	Weekly capacity and growth analysis — resource utilization trends, growth projections, and planning recommendations.	Every 24 hours
Custom Analysis	Create your own holistic analysis query with a custom prompt.	Configurable

---

Custom Alert Builder

Selecting Custom Alert opens the full alert builder with complete control over every parameter.

Alert Details

Field	Description
Rule Name	A descriptive name for the alert (e.g., "High CPU Usage on Core Router").
Description	Optional description explaining what this alert monitors and why.
Severity	The alert severity level: Critical, Warning, or Info. Severity affects how alerts are displayed and can be used to route notifications.
Enable this rule immediately	When checked, the rule starts evaluating as soon as it's created. Uncheck to create the rule in a disabled state.

Alert Type

Choose between two detection methods:

Static Threshold

Alerts when a metric value crosses a fixed threshold. Best for well-understood metrics with known acceptable ranges.

Example: Alert when CPU utilization is greater than 80%.

Baseline Deviation

Alerts when a metric value deviates significantly from its historical average. WhiteOwl calculates a baseline from the configured lookback period and triggers when the current value exceeds the baseline by the specified percentage. Best for metrics with variable "normal" ranges where a static threshold would cause false positives.

Example: Alert when inbound traffic from China exceeds 300% of its 7-day average.

Metric Configuration

Field	Description
Metric Source	The data source to monitor: SNMP, NetFlow, Synthetic Ping, Synthetic HTTP, Synthetic DNS, or Synthetic Traceroute.
Metric	The specific metric within the source. Options change based on the selected source. For SNMP: CPU Utilization, Memory Usage, Interface Utilization, Interface Errors, Interface Discards, etc. For NetFlow: Bits Per Second, Packets Per Second, Flows Per Second, Retransmit Rate, Average RTT, etc.
Device	The specific device to monitor (for SNMP and device-scoped metrics). Select a device from the dropdown, or leave as "All Devices" for global metrics.

Filter Conditions (Optional)

Narrow down which data triggers the alert. Click + Add condition to add filter criteria. This is useful for scoping flow-based alerts to specific traffic segments without creating per-device rules.

Example filters:

• Source Country = CN (alert only on traffic from China)
• Destination Port = 22 (alert only on SSH traffic)
• Source IP in subnet 10.0.0.0/8 (alert only on internal traffic)

Threshold Configuration

For Static Threshold

Field	Description
Operator	The comparison operator: Greater than (>), Less than (<), Greater than or equal (>=), Less than or equal (<=), Equal (=), Not equal (≠).
Value	The threshold value that triggers the alert (e.g., 80).
Unit	The unit of measurement: Percent (%), Bytes, Bits per second, Packets per second, Milliseconds, etc.

For Baseline Deviation

Field	Description
Deviation Percent	How far above the baseline the current value must be to trigger (e.g., 200 means 2x the baseline).
Minimum Absolute Value	A floor value below which the alert will not trigger, even if deviation is exceeded. Prevents false alarms on low-traffic metrics where small absolute changes cause large percentage deviations.
Lookback Days	Number of days of historical data to use for calculating the baseline average (e.g., 7 days).

Evaluation Settings

Controls how frequently and aggressively the alert engine checks for threshold breaches.

Field	Description
Evaluation Window	The time window (in seconds) over which the metric is aggregated for each check. For example, 300 seconds means the alert engine averages the metric over the last 5 minutes for each evaluation.
Evaluation Interval	How frequently (in seconds) the alert engine evaluates this rule. For example, 60 means the rule is checked every minute.
Consecutive Breaches	The number of consecutive evaluations that must exceed the threshold before the alert fires. Setting this to 3 with a 60-second interval means the metric must be above the threshold for 3 consecutive minutes before alerting. This reduces false alarms from transient spikes.

Tuning Consecutive Breaches

Start with 1 for critical alerts where immediate notification is important (e.g., device down). Use 3 or higher for metrics that naturally fluctuate (e.g., CPU, traffic volume) to avoid alert fatigue from brief spikes.

Notification Channels

WhiteOwl supports multiple notification channels for alert delivery. Click + Add Channel to add one or more channels to a rule. Multiple channels can be configured on a single rule — for example, sending to both Slack and a webhook simultaneously.

Webhook

Send a raw HTTP POST request with a JSON payload to any URL. Compatible with custom integrations, PagerDuty, Opsgenie, and any system that accepts webhook callbacks.

Field	Description
URL	The endpoint to POST to (e.g., https://webhook-endpoint.com/alerts).

Webhook Payload Builder

The webhook channel includes a powerful payload builder that lets you control exactly which data fields are included in the JSON payload sent to your endpoint.

Preset Field Groups:

Three preset buttons instantly add the most common fields for each alert type:

Preset	Fields Included
SNMP Default	Rule name, device name, metric, current value, threshold, timestamp, alert link.
NetFlow Default	Rule name, current value, threshold, source IP, destination IP, tag, timestamp, alert link.
Baseline Default	Rule name, current value, baseline value, deviation percent, timestamp, alert link.

Custom Field Selection:

Click + Add Field to open the field picker and add individual fields. Available fields are organized into categories:

Metrics:

Field	Description
Metric Name	What is being monitored (e.g., cpu_utilization, bps).
Current Value	The latest metric value that triggered the alert.
Threshold	The alert threshold value.
Baseline Value	The expected baseline (for baseline deviation alerts).
Deviation %	The percent deviation from baseline.

Device / Context:

Field	Description
Device Name	The hostname of the affected device.
Device IP	The management IP address.
Interface Name	The affected interface (for interface-scoped alerts).
Site Name	The site the device belongs to.

Flow Data (NetFlow alerts):

Field	Description
Source IP	Source IP address from flow data.
Destination IP	Destination IP address from flow data.
Source Port	Source port.
Destination Port	Destination port.
Protocol	IP protocol.
Application	Detected application name.
Country	GeoIP-resolved country.
ASN	Autonomous System Number.

Alert Metadata:

Field	Description
Rule Name	The alert rule name.
Rule ID	The numeric rule ID.
Severity	Alert severity (critical, warning, info).
Timestamp	When the alert fired.

Additional Options:

Option	Description
Include alert link	Adds an alert_url field with a direct link to the alert in the WhiteOwl UI.
Include chart URL	Adds a chart_url field with a link to a chart visualization of the metric at the time of the alert.

Example webhook payload:

{
  "rule_name": "High CPU on Core Switch",
  "severity": "critical",
  "current_value": "87.5",
  "threshold": "80",
  "device_name": "core-sw-1",
  "device_ip": "192.168.1.1",
  "metric": "cpu_usage",
  "timestamp": "2026-02-08T14:30:00Z",
  "alert_url": "https://whiteowl.local/alerts?rule_id=42"
}

Tailoring Payloads

Different downstream systems need different data. For Slack, keep it minimal (rule name, value, device). For PagerDuty or a SIEM, include the full context with IPs, ports, and enrichment data. The payload builder lets you customize per-rule without writing any code.

---

Slack

Send formatted alert notifications to a Slack channel via an incoming webhook.

Field	Description
Webhook URL	The Slack incoming webhook URL (e.g., https://hooks.slack.com/services/...). Create one in your Slack workspace under Apps → Incoming Webhooks.
Channel	The Slack channel to post to (e.g., #channel). This overrides the default channel configured on the webhook.
Bot Name	The display name for the alert bot (e.g., Chompy Alerts).
Emoji	The emoji icon for the bot (e.g., :bell:). Use Slack emoji shortcodes.

WhiteOwl formats Slack messages with color-coded severity indicators, metric details, and device context for easy scanning in a busy channel.

---

Email

Send alert notifications via email to one or more recipients.

Field	Description
Recipients	One or more email addresses to send alerts to.
Subject Template	Customizable email subject line.

Email Configuration

Email notifications require SMTP settings to be configured under Settings. See the Settings documentation for SMTP server configuration.

---

Syslog

Forward alert notifications as syslog messages to a remote syslog server. This is useful for integrating WhiteOwl alerts into existing log management or SIEM platforms.

Field	Description
Server	The syslog server hostname or IP address (e.g., syslog.example.com).
Port	The syslog port (default: 514).
Protocol	Transport protocol: UDP or TCP. UDP is the standard syslog transport; TCP provides reliable delivery.
Facility	The syslog facility code. Select from standard facilities such as local0 (16) through local7 (23). Using a localN facility makes it easy to filter WhiteOwl alerts from other syslog sources on your log server.

Alert messages are formatted as standard syslog records with the alert severity mapped to the corresponding syslog severity level.

---

Notification Mode

Controls when and how notifications are delivered. Select one of three modes:

Mode	Description
Automatic	Send the notification immediately when the alert fires. This is the default and recommended mode for most alerts.
Manual Approval	Hold the notification until an operator manually approves it in the WhiteOwl UI. Useful for non-urgent alerts where you want a human to review before notifying external systems.
Manual with Auto-Escalation	Hold for manual approval, but automatically send the notification after a configurable timeout if no one has reviewed it. Provides a human review window while ensuring critical alerts are never missed.

Alert Behavior

WhiteOwl's alerting engine includes several smart behaviors:

• Alert Suppression — Only one active alert instance is created per rule. Duplicate alerts are not generated while an existing alert for the same rule is still active.
• Auto Resolution — When the metric returns to within acceptable levels, the alert automatically resolves and the state changes from Firing to Resolved.
• Acknowledgment — Active alerts can be manually acknowledged by an operator, indicating the issue is being investigated.
• Baseline Caching — Baseline calculations are cached for 1 hour to reduce database load. Lookback period affects query performance — start with 7 days and adjust as needed.