Magento Search Performance Monitoring With the Elasticsearch Slow Log

1. Why slow Magento search requests often go unnoticed

Magento's own application layer usually does not show a detailed breakdown of how long a single search request actually took inside the cluster, only the total response time of the storefront page, which also includes network latency, PHP processing, and rendering. A single slow aggregation in layered navigation disappears inside that total time unless it is measured in isolation.

Without targeted monitoring, a gradual degradation usually only surfaces once users complain about sluggish search results or conversion metrics drop, at which point real revenue loss has already occurred. The slow log moves that detection point considerably earlier, since it logs every request above a threshold immediately and automatically.

2. Slow log basics: query phase versus fetch phase

The search slow log distinguishes between two phases of a search request: the query phase, in which every shard runs the actual search and determines hit IDs together with scores, and the fetch phase, in which the actual document content for the final top hits gets loaded. Both phases are logged separately, since they can have different causes of slowness, for example an expensive aggregation in the query phase versus large _source documents in the fetch phase.

In addition to the search slow log, a dedicated indexing slow log exists that logs slow write operations, particularly relevant for Magento during a full reindex, when large volumes of product documents get indexed in a short window. Both slow logs are configured independently of each other and land in separate log files by default.

3. Threshold configuration per index

Thresholds are set as dynamic index settings and can therefore be configured individually per Magento catalog index without restarting the cluster. Four levels are available, warn, info, debug, and trace, each configured independently for the query and fetch phases with its own time threshold, and requests exceeding a higher level automatically also get logged in the lower levels.

For production Magento clusters, a tiered configuration works well, with warn set to a value that truly marks critical requests, while debug sits noticeably lower to surface even early signs of degradation. A threshold set too low on a high log level, though, quickly produces an unwieldy log volume that obscures the actual problem rather than exposing it.

PUT /catalogsearch_fulltext_en/_settings
{
  "index.search.slowlog.threshold.query.warn": "3s",
  "index.search.slowlog.threshold.query.info": "1s",
  "index.search.slowlog.threshold.query.debug": "500ms",
  "index.search.slowlog.threshold.query.trace": "200ms",
  "index.search.slowlog.threshold.fetch.warn": "2s",
  "index.search.slowlog.threshold.fetch.info": "800ms",
  "index.search.slowlog.level": "info",
  "index.indexing.slowlog.threshold.index.warn": "10s",
  "index.indexing.slowlog.threshold.index.info": "5s",
  "index.indexing.slowlog.source": "1000"
}

4. Configuration across several Magento indices per store view

Magento creates a separate catalog index for every store view with its own language or price context, so a store with five store views also owns five independent indices in the cluster, each with its own slow log settings. A configuration limited to a single index therefore is not enough if every store view actually needs to be monitored.

A practical approach is an index template that automatically applies the slow log thresholds to every newly created catalog index, so monitoring keeps running seamlessly even after a full reindex creates fresh index names, without any manual extra step. Without such a template, thresholds would have to be reapplied manually after every reindex, something that gets forgotten quickly in practice.

PUT /_index_template/magento_catalog_slowlog
{
  "index_patterns": ["catalogsearch_fulltext_*", "magento2_product_*"],
  "template": {
    "settings": {
      "index.search.slowlog.threshold.query.warn": "3s",
      "index.search.slowlog.threshold.query.debug": "500ms",
      "index.search.slowlog.level": "info"
    }
  }
}

5. Reading and interpreting the slow log format

A typical slow log entry contains the elapsed time, the affected index and shard, the hit count, the full query DSL, and optionally source statistics if slowlog.source is enabled. The included query DSL is the most important part, since it shows exactly the structure that caused the slowness, for example a deep nesting of aggregations or a wildcard query on a field without a matching analyzer.

For Magento search requests, the logged query can be mapped back to its origin fairly reliably using characteristic aggregation names and filter fields, for instance an attribute facet in layered navigation whose field name directly matches the Magento attribute code. That mapping is the decisive step to move from an abstract time value in the log to a concrete cause traceable in the Magento code.

[2026-08-08T09:14:22,481][WARN ][index.search.slowlog.query] [node-1]
[catalogsearch_fulltext_en][3] took[3.4s], took_millis[3412],
total_hits[184302], types[], stats[], search_type[QUERY_THEN_FETCH],
total_shards[5], source[{"query":{"bool":{"filter":[{"terms":
{"category_ids":["24","31","57"]}}]}},"aggs":{"color_bucket":
{"terms":{"field":"color","size":500}}}}], id[]

6. Workflow: from a slow log entry to a concrete query optimization

The systematic process starts with reviewing warn and info entries daily or weekly, sorted by how often the same query pattern recurs rather than by individual occurrences, since a recurring pattern at high frequency usually has a bigger overall impact on user experience than a one-off outlier. From the logged query DSL, the next step is isolating which part, filter, aggregation, or sort, causes the largest share of the time.

The isolated query component is then tested separately with the profiler API to confirm the hypothesis from the slow log entry before touching the Magento code or the index configuration. After the optimization, the same request runs again and gets compared against the original time value to demonstrate the actual effect, instead of relying on a gut feeling.

7. Common causes of slow Magento search requests

In practice, three causes dominate: too many simultaneous terms aggregations in layered navigation, where every additional filter attribute adds another aggregation, wildcard or prefix queries on text fields without a matching analyzer, forcing a full term scan, and deep pagination through from and size, which becomes exponentially more expensive on large hit counts, since every shard has to sort all hits up to the requested offset.

Another case specific to Magento is an unintentionally high size on terms aggregations for attributes with many distinct values, for example a color or size facet with several hundred possible values, where an overly generous aggregation size ties up unnecessary memory and compute per shard.

8. Concrete optimization steps after a slow log finding

For too many facets in layered navigation, limiting simultaneously aggregated attributes to those actually relevant in the given category helps, instead of blanket aggregating every configured filter attribute on every request. For wildcard queries, a dedicated ngram or edge_ngram analyzer is usually the better fix, since it replaces the expensive runtime search with a structure prepared at index time.

For deep pagination, search_after combined with a stable sort criterion offers a noticeably cheaper alternative to large from values, though it only fits classic paginated Magento storefront navigation to a limited degree and is better suited to export functionality or internal batch processing of large result sets. For filter contexts without relevance scoring, such as pure category filters, filter should generally be used instead of must, so Elasticsearch can cache the result.

9. Integrating the slow log into comprehensive monitoring

Raw log files on the server are not very practical for day to day operations, which is why shipping logs into a dedicated analytics index, in the same or a separate cluster, makes sense, paired with a dashboard that aggregates the most frequent query patterns by total time share. On that basis, automated alerts can also be configured to trigger a notification whenever slow log entries suddenly spike.

It matters not to look at slow log analysis in isolation, but to correlate it with Magento side metrics such as reindex duration, page load time, and error rates, since a rise in slow search requests frequently coincides in time with a running reindex, a deployment, or a change to layered navigation, and this correlation often finds the actual cause faster than looking at the slow log alone.

10. Summary

11. FAQ: Slow Log Monitoring