An alert is triggered for each matching event.

Events processed through a filter alert are recorded by the system so that they triggered only once during execution.

Filter alerts do not support: Aggregate Query Functions, any Join Query Functions, copyEvent() and beta:repeating() functions.

The @id and @ingesttimestamp fields should be preserved during the filter query execution and thus cannot be overwritten or removed.

If present in the query result, the _bucket field will be removed when the alert query executes.

Filter alerts will process events, including catching up for past events, for up to 24 hours. This means that events are delivered as part of the filter query provided that the ingest delay for the cluster and time to process each action is smaller than 24 hours. While catching up, the alert will not process new events; if a single event is causing the alert of actions to fail, the alert does not trigger until that event is outside the catch-up limit.

The configuration value FILTER_ALERTS_MAX_CATCH_UP_LIMIT can be used to set the catch-up period using Relative Time Syntax.

Filter alerts will wait 10 minutes for query warnings about missing data to disappear. If they do not disappear within this time limit, the alert will give up and the data will not be triggered on.

The configuration parameter FILTER_ALERTS_MAX_WAIT_FOR_MISSING_DATA can be used to set the wait time using Relative Time Syntax.

Filter alerts are limited to a maximum of 100 triggers per minute, events exceeding this limit will be ignored.

From version 1.129, it is possible to set throttle limits in filter alerts to prevent the query triggering a configured action too often. See Setting Alert Throttle Period.

The environment variable ENABLE_FILTER_ALERTS must be set to true on every host in the cluster.

Filter alerts can be exported, and included in packages. See Packages for more information.