Skip to content
Content was updated: Jul 16, 2024
This is an archived version of the documentation downloaded from LogScale Documentation Archives. Up to date documentation, and documentation for later versions, is available on LogScale Documentation

## Alerts

##### Security Requirements and Controls

- `Change triggers and actions` permission

Alerts use live-queries that run continuously, trigger one or more actions when the query returns a result. Using alerts enables automation for notifying analysts and administrators through different integrations such as email or forward to another repo. This means you don't have to rely on a routine of checking LogScale and executing queries manually or programmatically and can detect problems as soon as they occur.

The alert types that are available:

- Aggregate Alerts are based on aggregating queries within a given search interval. Searches are run so that no time interval is missed and no time interval is checked twice, and queries are re-run in case of events causing a system shutdown.

- Filter Alerts are based on non-aggregate queries, and are configured to trigger the corresponding action at least once. Filter alerts also use a live query, but must not use an aggregate function for execution. Each event in the result set from the alert query triggers the actions associated with the alert.

- Legacy Alerts (formerly known as Standard Alerts) are triggered by queries that generate a result set. If the query is not already an aggregate query result, `tail(200)` is appended to the query to make it an aggregate query. Legacy alerts are only recommended for aggregate queries with explicit bucketing — those that use the `bucket()` or `timeChart()` query functions. Otherwise, opt for a filter or an aggregate alert instead. Legacy alerts do not offer backfills, and therefore aren't resilient against ingest delays.

The attributes of the three alert types are compared in the following table:

Feature | Aggregate Alerts | Filter Alerts | Legacy Alerts
--- | --- | --- | ---
Needs search window | Yes | No | Yes
Supports aggregates | Yes | No | Yes
Supports joins | No | No | Yes, but with Errors when Using Live join() Functions
Supports explicit bucketing | No | No | Yes
Is triggered by | Aggregate result | Single event | Aggregate result
Sends aggregate results to Actions | Yes | No | Yes
Invokes action | Sequentially | Concurrently | Sequentially
Retries after failure | Up to 24 hours | Up to 24 hours | As long as the query produces the same result
Can be throttled | Yes | Yes (from version 1.129) | Yes
Can be used in packages | Yes | Yes | Yes

#### Enter search term