Long Running Search Task
A search task has remained active beyond the runtime threshold. Long searches often reflect broad queries, large result sizes, expensive aggregations, regex or wildcard scans, or queries without tight filters.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Node |
| Domains | performance, search, stability, tasks |
You can customize these settings to adjust when AutoOps detects this event and presents the insight. Refer to AutoOps event settings for details.
The default customization settings are:
| Setting | Type | Default |
|---|---|---|
| Long running search task threshold in minutes | Integer | 1 |
The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.
Summary: There are 3 tasks that ran more than the 12 minutes threshold. The longest task running start time was 2026-03-15T14:22:00 UTC time. The longest task running time is 420 ms. ACTIVE TASKS: NodeName: logs-prod-000045- TaskId: es-data-01:4521
TaskSerialNumber: 12
TaskType: logs-prod-000045
Indices: 12
Reasons for increased latency:
Number of queried indices: 12
Filters should be added to avoid scanning the whole index
Size: 10000
Field with highest range: @timestamp
Highest Range: 2026-01-01
Regex Field: message
Regex Pattern: error|exception
Script Query: doc['price'].value * params.factor
Amount of nested aggregations: 12
Aggregation total buckets: 5000
Queries bucketing by high-cardinality fields, such as user.id, can increase memory pressure and end prematurely
The CASE function is lazy and can be slow depending on the number and nature of conditions
Field being dissected: message
DISSECT pattern: %{TIMESTAMP_ISO8601:ts} %{LOGLEVEL:level} %{GREEDYDATA:msg}
Field being groked: message
GROK pattern: %{TIMESTAMP_ISO8601:ts} %{LOGLEVEL:level} %{GREEDYDATA:msg}
Field being parsed: message
Regular expression: %{TIMESTAMP_ISO8601:ts} %{LOGLEVEL:level} %{GREEDYDATA:msg}
Field with highest range: @timestamp
Highest Range: 2026-01-01 Query:
{ "query": { "match_all": {} } }
SearchType: query_then_fetch
StartTimeInMillis: 1710502920000
RunningTimeInMinutes: 48
Cancellable: true
Action: indices:data/write/bulk
Headers: {} HISTORY TASKS: NodeName:logs-prod-000045- TaskId: es-data-01:4521
TaskSerialNumber: 12
TaskType: logs-prod-000045
Indices: 12
Reasons for increased latency:
Number of queried indices: 12
Filters should be added to avoid scanning the whole index
Size: 10000
Field with highest range: @timestamp
Highest Range: 2026-01-01
Regex Field: message
Regex Pattern: error|exception
Script Query: doc['price'].value * params.factor
Amount of nested aggregations: 12
Aggregation total buckets: 5000
Queries bucketing by high-cardinality fields, such as user.id, can increase memory pressure and end prematurely
The CASE function is lazy and can be slow depending on the number and nature of conditions
Field being dissected: message
DISSECT pattern: %{TIMESTAMP_ISO8601:ts} %{LOGLEVEL:level} %{GREEDYDATA:msg}
Field being groked: message
GROK pattern: %{TIMESTAMP_ISO8601:ts} %{LOGLEVEL:level} %{GREEDYDATA:msg}
Field being parsed: message
Regular expression: %{TIMESTAMP_ISO8601:ts} %{LOGLEVEL:level} %{GREEDYDATA:msg}
Field with highest range: @timestamp
Highest Range: 2026-01-01 Query:
{ "query": { "match_all": {} } }
SearchType: query_then_fetch
StartTimeInMillis: 1710502920000
RunningTimeInMinutes: 48
Cancellable: true
Action: indices:data/write/bulk
Headers: {}
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Improve search query
Condition: Shown when search task is not cancellable.
Review the long-running search in slow logs or task details, then optimize the query, filters, or scope so it finishes within an acceptable time.
Cancel long-running tasks
Condition: Shown when one or more long-running tasks are cancellable.
Cancel long-running tasks (es-data-01:4521, es-data-02:7788) that are affecting cluster stability. Use the action below.
POST _tasks/es-data-01:4521, es-data-02:7788/_cancel
Requires the manage cluster privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
Impact: Long running search task might affect the cluster performance and search stability. There can be many different underlying causes for long running search tasks, the most usual ones being:
- a search query with a very big size (for example, 10000) that seeks to retrieve a lot of documents,
- a search query over a large data set without any time range constraint, or with a time range that is too large,
- a search query with regular expression constraints or leading wildcard queries,
- an aggregation query with deeply nested aggregations over a large data set without appropriate constraints in the query section,
- an aggregation query with many buckets to be returned. to keep the latency of your search queries at bay, there a few best practices to keep in mind:
- pick the smallest size in order return as few documents as possible,
- search as few fields as possible, that is, always specify field names in query_string and multi_match queries,
- constrain your query as much as you can to only return what's strictly necessary or to compute aggregations on the smallest possible data set,
- return as few buckets as necessary in your aggregation queries,
- use regular expression and wildcard queries as sparingly as possible and eventually come up with better index-time analyzers so as to do most of the heavy lifting at indexing time instead of search time,
- avoid scripting everywhere possible,
- leverage the filter context instead of the query context if you're not interested in scores,
- try to denormalize your data and avoid joins (that is, parent-child) and nested fields as much as possible.