In Kibana, how does a filter pill differ from a KQL query typed in the query bar, and what pushes you off KQL?

middleshould knowfreq 51%

answer

Two inputs reach the same search
One is text, one is objects
Pills can be negated and pinned
KQL has no regex or fuzziness
Lucene mode or raw DSL escapes it

basics

~20 s

A KQL query is one text expression for the whole search; a filter pill is a discrete condition you can negate, disable or pin. KQL has no regex, fuzziness or boosting; for those, switch the bar to Lucene syntax.

solid answer

~50 s

Kibana's query bar holds one expression, written in KQL by default: field: value terms, and/or/not, parentheses, ranges such as duration_ms >= 250, wildcards, and field: * for existence. A filter pill is a separate structured condition sitting under the bar. Both end up in the same request, so the difference is ergonomic: a pill can be negated with a click, disabled and re-enabled while you test a hypothesis, and pinned so it follows you into another Kibana app.

You leave KQL when it cannot say the thing. It has no regular expressions, no fuzziness or proximity, and no relevance boosting — switching the bar to Lucene syntax brings those. For a condition neither language covers, an individual filter can be edited as raw Elasticsearch query DSL. Both escape hatches cost readability, so reach for them last.

Kibana's query bar holds **one expression**, written in **KQL** by default: `field: value` terms, `and`/`or`/`not`, parentheses, ranges such as `duration_ms >= 250`, wildcards, and `field: *` for existence. A **filter pill** is a separate structured condition sitting under the bar. Both end up in the same request, so the difference is ergonomic: a pill can be negated with a click, disabled and re-enabled while you test a hypothesis, and pinned so it follows you into another Kibana app. You leave KQL when it cannot say the thing. It has no regular expressions, no fuzziness or proximity, and no relevance boosting — switching the bar to **Lucene** syntax brings those. For a condition neither language covers, an individual filter can be edited as raw Elasticsearch query DSL. Both escape hatches cost readability, so reach for them last.

code

text · 1 line

text

duration_ms >= 4200 and court.region: "north-annex" and not status: cancelled

go deeper

for a junior

Know that Kibana's query bar defaults to KQL, that field: value joined with and, or and not is the everyday form, and that conditions can also be added as clickable filter pills underneath it.

for a middle

Explain what a pill gives you that query text does not — individual toggling, one-click negation, pinning across apps — and name at least two things KQL simply cannot express.

for a senior

Show judgement about when to leave KQL: what Lucene mode and a raw query DSL filter each buy you, and what they cost the next person who opens that saved search.

for a principal

Own the house style: whether teams standardise on KQL, how saved searches are curated so an investigation starts from a known narrowing, and what that choice does to onboarding time.

The two inputs to a Kibana search

Every search in Discover, and every panel query on a dashboard, is assembled from three things: the global time range, the text in the query bar, and any filter pills sitting beneath it. The bar holds exactly one expression, written in KQL (Kibana Query Language) by default; each pill is a separate structured condition. Kibana combines all of them into a single request to Elasticsearch, so the difference between the bar and the pills is not power — it is how you manage them while you work.

What KQL can express

field matches and quoted phrases: court.region: "north-annex", message: "hearing adjourned"
boolean composition with and, or, not, and parentheses for grouping
ranges on numbers and dates: duration_ms >= 250
existence: court.judge: * matches documents where the field has a value
wildcards in values and in field names: court.*: adjourned
nested-field syntax where the data requires it: parties:{ role: "counsel" and absent: true }
a bare term with no field name, matched across the view's fields

That covers the overwhelming majority of real log triage, which is why KQL is the default and the only mode that offers field and value autocomplete.

What it cannot, and the two escape hatches

Need	KQL	Query bar in Lucene mode	Filter edited as query DSL
Term, phrase, range, boolean	yes	yes	yes
Regular expression	no	yes	yes
Fuzzy or proximity matching	no	yes	yes
Relevance boosting	no	yes	yes
Nested-field condition	yes	no	yes
Anything needing a script or a geo shape	no	no	yes

The query bar can be switched from KQL to Lucene query syntax, which brings regular expressions, fuzziness and boosting with it. Below the bar, an individual filter can be opened and edited as raw Elasticsearch query DSL — the general escape hatch for a condition neither language can state.

A filter pill is an object; the query bar is a string

	Query bar text	Filter pill
Shape	one expression for the whole search	one condition per pill
Turning a single condition off	edit the text	toggle it, and toggle it back
Negation	write `not`	one click
Following you into another Kibana app	no	only when pinned
Escape hatch	switch the bar to Lucene	edit the pill as query DSL

Both are saved with the saved search or dashboard you save them on, and both are encoded in the URL, which is why a Kibana link is a reproducible investigation rather than a pointer to a screen.

How that plays out in practice

Working a courtroom-scheduling estate where a new region has just been brought up with no instrumentation, you end up with a stable narrowing and a moving hypothesis. The narrowing — region, hearing type, the 17 fields worth keeping in view — belongs in pills, because you will want to lift one at a time to see what it was hiding. The hypothesis of the moment — duration_ms >= 4200 and not status: cancelled across 2,318 hearings — belongs in the bar, because you retype it every thirty seconds.

Two habits separate people who are fast in Kibana from people who are not:

Pin the filters worth keeping. A pinned filter stays applied as you move between Kibana apps, so a narrowing built in Discover is still there when you open a dashboard. An unpinned one belongs to the app you built it in and is left behind.
Save the search once it is worth keeping. A saved search carries its data view, its query text and its pills together, and can be dropped onto a dashboard as a panel — which is how one person's investigation becomes the place the next person starts.

The cost of leaving KQL

Every escape hatch costs readability. A pill edited as raw query DSL renders as an opaque custom filter that a teammate cannot skim, cannot adjust in the form editor, and will usually delete rather than try to understand. Switching the bar to Lucene changes the language of the whole expression rather than one clause, and takes the autocomplete with it. A regular expression over a wide time range is also the most expensive thing on this list, and the bar puts it one keystroke away.

So the order to reach for things is: KQL first; a filter pill whenever you want a switch rather than a sentence; Lucene when you genuinely need regex or fuzziness; raw query DSL last — and when you do use it, say why in the saved search's title or description, because the next reader has no other clue.

## The two inputs to a Kibana search Every search in Discover, and every panel query on a dashboard, is assembled from three things: the **global time range**, the text in the **query bar**, and any **filter pills** sitting beneath it. The bar holds exactly one expression, written in **KQL** (Kibana Query Language) by default; each pill is a separate structured condition. Kibana combines all of them into a single request to Elasticsearch, so the difference between the bar and the pills is not power — it is how you manage them while you work. ## What KQL can express - field matches and quoted phrases: `court.region: "north-annex"`, `message: "hearing adjourned"` - boolean composition with `and`, `or`, `not`, and parentheses for grouping - ranges on numbers and dates: `duration_ms >= 250` - existence: `court.judge: *` matches documents where the field has a value - wildcards in values and in field names: `court.*: adjourned` - nested-field syntax where the data requires it: `parties:{ role: "counsel" and absent: true }` - a bare term with no field name, matched across the view's fields That covers the overwhelming majority of real log triage, which is why KQL is the default and the only mode that offers field and value autocomplete. ## What it cannot, and the two escape hatches | Need | KQL | Query bar in Lucene mode | Filter edited as query DSL | | --- | --- | --- | --- | | Term, phrase, range, boolean | yes | yes | yes | | Regular expression | no | yes | yes | | Fuzzy or proximity matching | no | yes | yes | | Relevance boosting | no | yes | yes | | Nested-field condition | yes | no | yes | | Anything needing a script or a geo shape | no | no | yes | The query bar can be switched from KQL to **Lucene** query syntax, which brings regular expressions, fuzziness and boosting with it. Below the bar, an individual filter can be opened and edited as raw Elasticsearch query DSL — the general escape hatch for a condition neither language can state. ## A filter pill is an object; the query bar is a string | | Query bar text | Filter pill | | --- | --- | --- | | Shape | one expression for the whole search | one condition per pill | | Turning a single condition off | edit the text | toggle it, and toggle it back | | Negation | write `not` | one click | | Following you into another Kibana app | no | only when pinned | | Escape hatch | switch the bar to Lucene | edit the pill as query DSL | Both are saved with the saved search or dashboard you save them on, and both are encoded in the URL, which is why a Kibana link is a reproducible investigation rather than a pointer to a screen. ## How that plays out in practice Working a courtroom-scheduling estate where a new region has just been brought up with no instrumentation, you end up with a stable narrowing and a moving hypothesis. The narrowing — region, hearing type, the 17 fields worth keeping in view — belongs in pills, because you will want to lift one at a time to see what it was hiding. The hypothesis of the moment — `duration_ms >= 4200 and not status: cancelled` across 2,318 hearings — belongs in the bar, because you retype it every thirty seconds. Two habits separate people who are fast in Kibana from people who are not: 1. **Pin the filters worth keeping.** A pinned filter stays applied as you move between Kibana apps, so a narrowing built in Discover is still there when you open a dashboard. An unpinned one belongs to the app you built it in and is left behind. 2. **Save the search once it is worth keeping.** A saved search carries its data view, its query text and its pills together, and can be dropped onto a dashboard as a panel — which is how one person's investigation becomes the place the next person starts. ## The cost of leaving KQL Every escape hatch costs readability. A pill edited as raw query DSL renders as an opaque custom filter that a teammate cannot skim, cannot adjust in the form editor, and will usually delete rather than try to understand. Switching the bar to Lucene changes the language of the whole expression rather than one clause, and takes the autocomplete with it. A regular expression over a wide time range is also the most expensive thing on this list, and the bar puts it one keystroke away. So the order to reach for things is: KQL first; a filter pill whenever you want a switch rather than a sentence; Lucene when you genuinely need regex or fuzziness; raw query DSL last — and when you do use it, say why in the saved search's title or description, because the next reader has no other clue.

Someone pastes a query using a fuzziness operator into the Kibana query bar and gets nothing back. What happened?
The bar is almost certainly in KQL mode, and KQL has no fuzzy operator, so the expression does not mean what its author intended. Switching the bar to Lucene query syntax gives you fuzziness, proximity, regular expressions and boosting. The trade is that the whole expression changes language, and the field and value autocomplete goes with it.
Why would you pin a filter in Kibana?
A pinned filter keeps applying as you move between Kibana apps, so a narrowing you built while exploring in Discover is still in force when you open a dashboard. An unpinned filter belongs to the app you created it in and is left behind. Pinning is how you carry one investigation's context across several surfaces without rebuilding it each time.
When is editing a filter as raw query DSL the right call, and what does it cost?
It is right when the condition cannot be stated in KQL or built in the filter form — something needing a script, a geo shape, or a specific clause structure. The cost is readability: the pill becomes an opaque custom filter a teammate cannot skim or adjust in the form editor, so it is usually deleted rather than understood. Explain it in the saved search's title or description.

Filter pills are switches on a control panel; the query bar is the scratchpad you retype every thirty seconds.

saying these in an interview costs you the question

Thinks KQL and Lucene query syntax are the same language
Expects regular expressions or fuzziness to work in KQL
Believes disabling a filter pill deletes it
Assumes every filter follows you between Kibana apps
Claims a filter can express nothing the query bar cannot

In Kibana, how does a filter pill differ from a KQL query typed in the query bar, and what pushes you off KQL?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The two inputs to a Kibana search

What KQL can express

What it cannot, and the two escape hatches

A filter pill is an object; the query bar is a string

How that plays out in practice

The cost of leaving KQL

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

The two inputs to a Kibana search

What KQL can express

What it cannot, and the two escape hatches

A filter pill is an object; the query bar is a string

How that plays out in practice

The cost of leaving KQL

answer

go deeper