Skip to content

Understand query behavior in alerts and incident views

Create reliable alerts by understanding how Coralogix evaluates queries. When an alert triggers, its query runs against the real-time data stream. When you later inspect the alert in a Case or Incident view, the same query runs against archived data. Because the real-time and archive engines handle certain Lucene patterns differently, results can differ in specific edge cases.

Coralogix is working to align these engines. The guidance below helps you avoid the patterns most likely to produce discrepancies.

Building a Lucene query in the Query Builder and switching between real-time and archived views

How query evaluation works

Coralogix processes alert queries in two stages:

  • Real-time evaluation: Processes incoming log data as it arrives and determines whether an alert triggers
  • Case or Incident data view: Queries archived data from the past 24 hours when you inspect an alert in a Case or Incident view

Because the Case and Incident views query archived data rather than the real-time stream, some Lucene patterns behave differently between these two contexts.

Where differences can occur

Behavior differences can affect:

  • Standard alerts: Alert evaluation compared to the Case or Incident data view
  • Events2Metrics: Including Logs2Metrics and Spans2Metrics

Review the patterns below if you:

  • Use wildcards, regex, or range operators
  • Check field existence
  • Notice mismatched results between alert triggers and Case or Incident views
  • See unexpected Events2Metrics output

Query compatibility reference

Use this table to understand how different Lucene query patterns behave in real-time evaluation compared to the archived data view, and where discrepancies can occur.
Query patternReal-time evaluationArchived data viewRisk of discrepancy
Simple terms (error)SupportedSupportedNone
Boolean operators (AND, OR, NOT)SupportedSupportedNone
Phrase match ("connection refused")SupportedSupportedLow
Field match (status:500)SupportedSupportedNone
Suffix wildcard (msg:error*)SupportedSupportedLow
Leading wildcard (msg:*error)Special handlingPattern matchHigh
Wildcard in compound queryMisinterpretedPattern matchHigh
Special characters (#, @, /)TokenizedLiteral matchHigh
RegexSupportedSupportedMedium
Numeric rangeSupportedSupportedLow
String rangeNot executedSupportedHigh
Field existsSupportedSupportedMedium
Boost / fuzzy / proximityIgnoredRejectedHigh

Wildcards

Wildcards can produce inconsistent results between engines.

  • Suffix wildcards (field:value*) behave consistently
  • Leading wildcards (field:*value) behave differently across engines
  • Wildcards in compound queries can fail silently

Use regex instead of wildcards:

-- Avoid
msg:*error

-- Use
msg.keyword:/.*error/

Regex patterns

Regex works in both engines. Follow these rules:

  • Use .keyword fields for non-tokenized values
  • Make anchors (^, $) explicit
  • Avoid extremely complex patterns
user.name.keyword:/.*@example\.org/

Numeric comparisons

Use Lucene range syntax with .numeric fields:

-- Avoid
event.latency>100

-- Use
event.latency.numeric:[100 TO *]

String ranges

Real-time evaluation does not execute string ranges. Use explicit values or regex:

-- Avoid
severity:["error" TO "critical"]

-- Use
severity:error OR severity:critical

Field existence checks

Check field existence using _exists_:field or field:*.

Real-time evaluation treats empty objects, arrays, or null values as non-existing. Archive queries might treat them as existing. Normalize data at ingest if you need consistent behavior for empty structures.

Boost, fuzzy, and proximity operators

These operators are inconsistent across engines:

  • Real-time evaluation accepts but ignores them
  • The archived data view rejects them

Remove these modifiers from queries:

foo^2 → foo
foo~2 → foo
"foo bar"~5 → "foo bar"

Special characters

Special characters (#, @, /) are processed differently across engines. Use regex with .keyword for consistent results:

body.keyword:/.*#4.*/

Always escape special characters such as dashes:

status:"pre\-production"

CIDR IP matching

Real-time evaluation supports CIDR notation. If results differ in the archived data view, use a regex fallback:

source.ip.keyword:/10\..*/

Follow these guidelines to create reliable alert queries:

  1. Use simple terms and boolean operators
  2. Replace wildcards with regex
  3. Use .keyword for regex and .numeric for numeric ranges
  4. Make regex anchors explicit
  5. Avoid boost, fuzzy, and proximity operators
  6. Avoid string range queries
  7. Scope queries with field names when using special characters
  8. Use regex for exact matching with special characters
  9. Escape special characters consistently
  10. Validate results in the Case or Incident data view after creating or updating alerts
Need help? Contact Support.
What's new? Find out here.
LLM? Read llms.txt.
Previous Lucene Query Builder
Next Alert Suppression Rules