At a glance
The ten slowest searches the cluster has logged over the last 24 hours, broken down by row: each entry shows the query, the index it hit, how long it took (took), and the shard it was slow on. This is the diagnostic detail behind the headline performance cards. When Slow-Query Rate % or Search Latency p99 (ms) climbs, this card names the exact queries to optimise.
What it tracks
The card reads the search slowlog over a trailing 24-hour window and surfaces the ten entries with the highesttook durations, sorted slowest first. Each row carries the query source, target index, duration and the shard that breached the slowlog threshold, so a platform team can move straight from “search is slow” to “this aggregation on the products index is the culprit”. Typical offenders are deep pagination (from + size running into the thousands), large or nested aggregations, leading-wildcard queries, and scripted sorts. Because the window is 24 hours, the card captures overnight batch queries and one-off pathological searches that a short-window percentile card would miss. It has no alert threshold of its own; it is a drill-down companion to the alerting performance cards.
Reconciling against the source
Cross-check against Elasticsearch’s own search slowlog file (<cluster>_index_search_slowlog.json), which records every slow entry with took, the query source and the shard. Confirm the slowlog threshold via GET /<index>/_settings?include_defaults=true&filter_path=**.slowlog, and use GET /<index>/_search?profile=true to re-run a suspect query and see its phase-by-phase timing. In managed services the same slowlog is shipped to Elastic Cloud logging, AWS OpenSearch/Elasticsearch Service CloudWatch Logs, or the Bonsai dashboard.