Persisted Aggregations

Persisted aggregations allow you to define, schedule, and query aggregated metrics from log data.

A persisted aggregation is a scheduled query that summarizes data from a source repository and writes results to a dedicated persisted aggregation repository. You can calculate metrics such as count, average, sum, and percentiles on a fixed schedule.

Because LogScale calculates and caches results in advance, queries run faster and consume fewer compute resources than real-time aggregations. Results are stored as events and can be queried directly, instead of querying raw historical logs.

Results are stored independently of the source repository, allowing you to retain aggregated data for longer periods at reduced storage costs. Persisted aggregations are well-suited for high-frequency analytic workloads where query speed and resource efficiency are priorities.

This section focuses on the query language syntax requirements and restrictions for persisted aggregations.

For information about creating and managing persisted aggregations through the user interface instead, see Persisted Aggregation Management.

Key Capabilities

  • Define aggregation queries that calculate metrics such as count, average, sum, and percentiles. See Supported Functions for the functions that can be used in persisted aggregation queries.

  • Schedule automatic recalculation at a fixed interval, such as every minute, hourly, daily, weekly, or yearly. See Configure Persisted Aggregation Properties for information on how to configure the scheduling in persisted aggregations.

  • Store results in a dedicated persisted aggregation repository with a user-defined tag. For more information, see Persisted Aggregation Repositories.

  • Backfill historical data so that results reflect what would have been generated had the aggregation been running from an earlier point in time. See Configure Persisted Aggregation Properties for information on how to configure the historical backfill period.

  • Query persisted results directly using CrowdStrike Query Language instead of querying raw historical logs.

Use Cases

Persisted aggregations are particularly useful for:

  • Dashboard queries — Pre-calculate metrics for dashboards that refresh frequently, avoiding repeated expensive aggregations.

  • Baseline analysis — Compare current metrics against historical trends by querying pre-aggregated historical data.

  • Alert queries — Run alerts against pre-aggregated data for faster evaluation and reduced resource consumption.

  • Long-term trend analysis — Maintain aggregated metrics over extended time periods without storing raw events.

Query Language Requirements

Persisted aggregation queries must follow these language requirements:

  • The query must contain at least one aggregator function.

  • Saved queries are not allowed.

  • Query parameters are not allowed.

  • Cartesian products are not allowed.

  • Field aliasing is not allowed.

  • Deprecated functions and arguments are not supported.

  • The query cannot reference other persisted aggregations.

Supported Functions

The following functions can be used in persisted aggregation queries.


Repository Selection

Persisted aggregation results must be written to a dedicated persisted aggregation repository. You cannot write results to a standard LogScale repository. These repositories must be created before you create a persisted aggregation.

You can create multiple persisted aggregation repositories and group logically related aggregations together. Grouping aggregations into separate repositories provides the following benefits:

  • Retention periods can be set independently per repository.

  • Repository-level permissions control which users can access which aggregation results.

  • Auth prefixes can be used for further subdivision within a repository where finer access control is required.

For detailed information about creating and configuring persisted aggregation repositories, see Persisted Aggregation Repositories.

Tagging System

Each persisted aggregation uses a tag to identify its result events. Each result event carries exactly one tag identifying the persisted aggregation that produced it. No other user-defined tags are written to result events.

For information about tag requirements and constraints, see Configure Persisted Aggregation Properties.

Querying Persisted Aggregation Data

You query persisted aggregation results using CrowdStrike Query Language.

Because results are precomputed and stored as events in the destination repository, queries against persisted aggregation data run faster than equivalent queries against raw historical logs.

Each result event contains the following fields:

Table: Result event fields

Field Description
User-defined fields Fields produced by the aggregation query. For example, a query using groupBy([UserName], function=count(as=total)) produces events with UserName and total fields.
@timestamp Set to the interval start time.
@ingesttimestamp The time the result event was written to the persisted aggregation repository.
@pa_interval_start The start of the interval this result covers. Same value as @timestamp.
@pa_interval_end The end of the interval this result covers.

Each result event carries exactly one tag identifying the persisted aggregation that produced it. This tag is the value you defined at creation time. No other user-defined tags are written to result events.

The system reserves the @pa field prefix for metadata. Do not use this prefix when naming aggregation output fields.

To read persisted aggregation results programmatically, use the readPersistedAggregation() function. This function provides direct access to stored aggregation results with optional filtering by time range and grouping by a specified interval.