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.

Events should be delivered as part of the filter query providing that the ingest delay for the cluster and time to process each action is smaller than one hour.

Filter alerts do not support: aggregate queries, any Join Query Functions, copyEvent(), beta:repeating() functions in queries.

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

The _bucket field, if present in the query result 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 allows filter alerts to account for ingest and delays in processing actions. 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.

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.

It is possible to set throttle limits in Filter Alerts to prevent the query triggering a configured action too often or too frequently. See Setting Alert Throttle Period.