Use regular expressions in Kibana without confusing KQL and Lucene

KQL does not support slash-delimited regular expressions. In a Kibana search bar that supports Lucene mode, switch from KQL to Lucene and use field:/pattern/. Alternatively, submit a regexp query through Elasticsearch Query DSL.

Before choosing a pattern, inspect the field mapping. Regular-expression queries operate on indexed terms, not arbitrary original JSON values.

Use the simplest query for the field type

For a numeric HTTP status, a KQL range is clearer than regex:

status >= 400 and status < 500

For a field mapped as ip, use a CIDR filter when appropriate:

client_ip: 10.0.0.0/16

If these values are instead stored in keyword fields, Lucene regex examples include:

Use the field names your mapping actually defines. The IP regex checks a textual shape, not valid octet ranges. The domain example does not include the bare example.com. For a simple level choice, KQL level.keyword: (ERROR or FATAL) is easier to read.

Use Query DSL when you need explicit control

In Dev Tools, for a keyword field named host.keyword:

GET your-index/_search
{
  "query": {
    "regexp": {
      "host.keyword": { "value": ".*\\.example\\.com" }
    }
  }
}

An editor that expects only a query clause needs the inner regexp object, not the whole search body. JSON requires a second backslash for each regex escape. The Lucene search bar has no JSON string layer, so do not copy JSON's doubled backslashes into it blindly.

Know the matching and cost limits

Lucene regex matches the whole indexed term. Its syntax differs from PCRE: familiar anchors such as ^ and $ are unsupported, and lookarounds are not interchangeable. On analyzed text fields, the terms may be individual words, so an expression for the full original message can fail unexpectedly.

A fixed prefix can narrow the terms considered. Leading .* and complex patterns can be expensive, and search.allow_expensive_queries: false blocks regexp queries. Reduce the time range and choose exact values, numeric ranges, CIDR filters, or prefix queries where possible. For a frequently used distinction, extract a dedicated field during ingestion.

References: KQL, Lucene regex syntax, and regexp query limits.