Anomaly Detection Types

Impossible Travel Anomalies

This detection type searches for authentication events for users who appear to log in from geographically distant locations within an impossible time window.

Prerequisites

Before proceeding, ensure that the following prerequisites are met:

• Ensure your Graylog pipeline or processing configuration applies GeoIP lookups to source IP addresses in your authentication logs, populating the source_geo_* fields.

• Verify that login and authentication events include a consistent user identity field.

Impossible Travel Explained

The detector runs on a scheduled interval to identify users with multiple login events that include both identity and geolocation data. It compares each user’s current login activity with their most recent prior login, evaluating whether the distance and time between events imply an unrealistic travel speed. An event is generated when the distance exceeds the configured threshold and the calculated travel speed surpasses the allowed limit, enabling detection when logins fall outside the defined time window.

Configure Impossible Travel Detector

To create an Impossible Travel Anomalies detector:

1. Navigate to Alerts > Event Definitions.

2. Click Create Event Definition.

3. Select Anomaly Events as the condition type, then pick Impossible Travel Anomalies from the Detection Type dropdown.

The Impossible Travel Anomalies detection type includes the following configuration options:

Field	Description
Search Query (optional)	An optional Lucene query to filter which messages are considered. Use this to scope detection to specific log sources or event types (e.g. action:login).
Search Filters (optional)	Search filters let you reuse query snippets to refine your search result.
Streams	Set this value to the stream that contains your events (e.g. windows-security-logs or auth-logs) so the detector evaluates the correct log source.
Stream Categories (optional)	Select stream categories the search should include. This helps when filtering or organizing at scale.
Use Cron Scheduling	Enables custom scheduling using a cron expression. Use this option to automate the process of running this event definition at a fixed time, date, or other interval. Cron expression: A cron expression is a string of fields separated by white space. Graylog uses Quartz cron syntax, for example: <second> <minute> <hour> <day of month> <month> <day of week> <year>
Execute search every	Sets how frequently the detection logic runs to find impossible time travel anomalies.
Window Delay	Offsets the search window backward by the value specified, to account for ingestion latency, ensuring late-arriving log messages are included in detection.
User Field	The message field containing the user identity (e.g. user_name, source_user). This is how the detector associates login events with a specific user.
Distance Threshold	The minimum geographic distance between two consecutive logins required to consider them for alerting. The default setting is 900 km in 1 hour. You have the option to measure distance in kilometers or miles.
Time Threshold	This settings works in combination with the distance threshold and defines the maximum plausible travel speed. Logins that exceed this speed over the distance threshold will trigger an alert.
Lookback Period	How far back to search for a user's previous login when comparing locations. This determines how long of a gap between logins the detector can bridge.
Enable (checkbox)	This setting automatically activates the event definition.

Detecting Account Compromise with Impossible Travel Example

A security analyst wants to identify potentially compromised user accounts by detecting logins from geographically distant locations within an impossible period of time.

The analyst creates an event definition using Anomaly Events as the condition type, selects Impossible Travel Anomalies as the detection type, and sets the distance threshold to 3,000 miles and the time window to 30 minutes.

When this event definition is enabled, Graylog evaluates authentication activity using the Impossible Travel detection logic. If a user logs in from New York and then, within 10 minutes, from Singapore, the detector flags the activity as anomalous and Graylog generates an event because the travel is impossible.

The analyst reviews the triggered event, runs a replay search to examine related authentication logs, and confirms that the activity is likely unauthorized. The analyst then initiates required incident response actions.

Log Volume Anomalies

This detection type checks for abnormal increases or decreases in log volume from a specific source compared to its historical baseline.

Log Volume Anomalies Explained

The detector groups messages into fixed time buckets based on the Execute search every interval and calculates a baseline from historical buckets using the selected statistic (AVG, P95, or P99). It then compares the current bucket count against this baseline to detect significant increases (HIGH) or decreases (LOW) based on the configured threshold percentage. Alerting is suppressed if there is insufficient historical data, inadequate data coverage, or a zero baseline.

Warning: The detector silently skips alerting (produces no event) when any of these conditions apply:

Condition	Reason
Fewer than 2 total buckets returned	Not enough data to separate current from historical.
Data coverage ratio below the minimum data ratio	Historical data is too sparse to establish a reliable baseline.

Configure Log Volume Anomalies Detector

To create a Log Volume Anomalies detector:

1. Navigate to Alerts > Event Definitions

2. Click Create Event Definition.

3. Select Anomaly Events as the condition type, then pick Log Volume Anomalies from the Detection Type dropdown.

The Log Volume Anomalies detection type includes the following configuration options:

Field	Description
Search Query (optional)	Optional Lucene query to filter messages before counting. When empty, all messages in the configured streams are counted.
Search Filters (optional)	Search filters let you reuse query snippets to refine your search result.
Streams	Set this value to the stream that contains your events (e.g. windows-security-logs or auth-logs) so the detector evaluates the correct log source.
Stream Categories (optional)	Select stream categories the search should include. This helps when filtering or organizing at scale.
Use Cron Scheduling	Enables custom scheduling using a cron expression. Use this option to automate the process of running this event definition at a fixed time, date, or other interval. Cron expression: A cron expression is a string of fields separated by white space. Graylog uses Quartz cron syntax, for example: <second> <minute> <hour> <day of month> <month> <day of week> <year>
Execute search every	How often the detector runs. Also defines the bucket size for aggregation. The default is 15 minutes.
Window Delay	Offsets the search window backward by the value specified, to account for ingestion latency, ensuring late-arriving log messages are included in detection.
Historical Time Period	How far back to look when computing the historical baseline. Can be configured in hours or days. The default is 24 hours.
Baseline Statistic	The statistic used to summarize historical bucket counts into a single baseline value. Select from the dropdown. The default is the 95th Percentile.
Alert Direction	This setting determines how Graylog alerts on volume spikes or drops. High (volume spike) alerts when current count exceeds the baseline threshold. Low (volume drop) alerts when current count falls below the baseline threshold. The default is High (volume spike).
Threshold Percent	The percentage of baseline that triggers an alert. For High (volume spike), the default value of 300 means "alert when volume is 3x the baseline." For Low (volume drop), a value of 50 means "alert when volume drops to half the baseline." Value specified must be greater than 0.
Minimum Data Ratio	Minimum fraction of expected historical buckets that must contain data before the detector will alert. Prevents false positives when data is sparse. The default value of 0.75 means at least 75% of historical buckets must be non-empty. Range: 0–1.

Detecting Log Ingestion Issues with Sudden Log Volume Fluctuation Example

A security analyst wants to detect abnormal changes in log volume that may indicate data loss, misconfigured sources, or malicious activity.

The analyst creates an event definition using the Log Volume Anomalies detection type logic and sets thresholds for a 300% increase or a 90% decrease in log volume over a 15-minute window.

After deployment, Graylog generates an event when a critical firewall stops sending logs and volume drops sharply below expected levels. This alerts the analyst to a potential logging failure or intentional disruption.

The analyst reviews the event, runs a replay search to confirm the drop in incoming messages, and investigates the affected source. Based on the findings, the analyst takes corrective action, such as restoring log forwarding or escalating a potential security incident.