Introducing SPARKLINE in ES|QL: Spot trends at a glance

Get hands-on with Elasticsearch: Dive into our sample notebooks in the Elasticsearch Labs repo, start a free cloud trial, or try Elastic on your local machine now.

When you run a STATS ... BY query and get back dozens or hundreds of results (log patterns, hosts, services, status codes), the counts alone don't tell you what's happening over time. Is the error count or log pattern climbing or settling down? Is it within the usual range? To answer those questions today, you either build a separate time-series visualization or eyeball the numbers and hope for the best.

This can be a lot of effort, time, and context switching for what should be just a glance. In this blog, we explain how Elasticsearch Query Language’s (ES|QL’s) SPARKLINE works, what it does, and how to get started.

How it works

SPARKLINE is an ES|QL aggregate function with a straightforward signature:

SPARKLINE(aggregation, key, buckets, from, to)

• aggregation: Expression that calculates the y-axis value, including any supported aggregation: COUNT(*), SUM(bytes), AVG(latency), or others.

• key: Date expression from which to derive buckets.

• buckets: Target number of buckets.

• from / to: The time range boundaries. (In Kibana, they bind to the time picker via query parameters.)

Under the hood, SPARKLINE buckets the time range, computes the aggregation per bucket, and packs the results into a single ordered array. Empty buckets are zero-filled so every group shares the same x-axis grid for fast, easy visual comparison.

The function composes naturally with STATS ... BY, so you can combine it with any grouping.

Where sparklines shine

The first place you'll see SPARKLINE in action is Discover's log pattern analysis, starting 9.5. When you run a CATEGORIZE query, Discover constructs the SPARKLINE query under the hood and renders trend lines next to each pattern. You don't write SPARKLINE yourself here; Discover handles it when you use the “identify patterns” option in the ES|QL editor. The result is immediate: You scan dozens of log patterns and instantly see which ones are spiking right now versus which have been steady all day.

Here’s the query under the hood:

FROM app-logs-*
| WHERE @timestamp <= ?_tend AND @timestamp > ?_tstart
| STATS count = COUNT(*), sparkline = SPARKLINE(COUNT(*), @timestamp, 50, ?_tstart, ?_tend) BY pattern = CATEGORIZE(message)
| SORT count DESC

Consider a platform team investigating how they can cut logging costs. They point Discover at tens of millions of documents and let CATEGORIZE cluster them into patterns. Two patterns rise to the top: verbose lifecycle messages like "fetching resource..." and "completed resource...", each with several millions of hits. The sparklines next to those rows tell the rest of the story: flat, steady streams running around the clock. Not incident-driven. Not bursty. Just constant noise, silently consuming hundreds of terabytes of storage.

The fix in cases like this is usually straightforward: Adjust log levels, drop the pattern at ingest, or route it to a cheaper tier. The hard part was always finding it. With log pattern analysis and inline sparklines in ES|QL, that discovery takes seconds instead of hours. 

Elastic’s internal site reliability engineering (SRE) teams routinely use log pattern analysis successfully, using every ES|QL enhancement. 

These are just some concrete examples. Break down request counts by region, and see which regions are trending up. Compare latency across container IDs. Monitor queue depths by consumer group. The uses are endless.

Simple by design

We deliberately kept SPARKLINE focused:

• It's an aggregate function, not a new command. It composes with existing STATS ... BY syntax, so there's nothing new to learn structurally.

• It returns data that the consumer can render in context. The function produces an array of values. How those values are rendered, as a mini-chart in Discover, a line in a notebook, or a JSON array in an API response, is up to the consumer.

• It fills empty buckets. Every group gets the same number of values aligned to the same time grid. This is a deliberate choice: Sparklines are most useful when you can compare shapes across rows at a glance, and that requires consistent alignment.

The pattern is always the same: one query, many trend lines, instant visual triage.

What's next

SPARKLINE ships as a technical preview in Elasticsearch 9.5. Future work includes rendering sparklines in more ES|QL surfaces, beyond the initial integration, with the CATEGORIZE context in Kibana. This includes dashboards but also Elastic Observability use cases like the following:

In application performance monitoring (APM) workflows, engineers routinely analyze rate, errors, and duration (RED) metrics to understand service health. The challenge is that aggregate numbers hide dimensional outliers. A service might look healthy overall, but one region, one container, or one newly deployed version could be quietly degrading.

Today, the Elastic APM UI lets you break down metrics by transaction name, but root-cause analysis requires slicing by arbitrary dimensions: availability zone, service version, container ID, cloud region. SPARKLINE can make this practical. Break down error rate by service.version, and instantly see which version's trend line diverges from the pack.

Get started

SPARKLINE is available in Elasticsearch 9.5 as a technical preview. Try it with the ES|QL _query API or in Kibana's Discover. Check the SPARKLINE function reference for the full syntax and supported types.

The release and timing of any features or functionality described in this post remain at Elastic's sole discretion. Any features or functionality not currently available may not be delivered on time or at all.