Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fuser-guides%2Falerting%2Flucene-query-builder%2Fquery-behavior.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fdocs-docusaurus.kinsta.page%2Fuser-guides%2Falerting%2Flucene-query-builder%2Fquery-behavior.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

# 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](/assets/images/lucene-build-2f8e878ac85ba7a395da6e4dc168f0aa.webp)](https://docs-docusaurus.kinsta.page/assets/images/lucene-build-2f8e878ac85ba7a395da6e4dc168f0aa.webp)

## How query evaluation works[​](#how-query-evaluation-works "Direct link to 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[​](#where-differences-can-occur "Direct link to 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[​](#query-compatibility-reference "Direct link to 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 pattern                          | Real-time evaluation | Archived data view | Risk of discrepancy |
| -------------------------------------- | -------------------- | ------------------ | ------------------- |
| Simple terms (`error`)                 | Supported            | Supported          | None                |
| Boolean operators (`AND`, `OR`, `NOT`) | Supported            | Supported          | None                |
| Phrase match (`"connection refused"`)  | Supported            | Supported          | Low                 |
| Field match (`status:500`)             | Supported            | Supported          | None                |
| Suffix wildcard (`msg:error*`)         | Supported            | Supported          | Low                 |
| Leading wildcard (`msg:*error`)        | Special handling     | Pattern match      | High                |
| Wildcard in compound query             | Misinterpreted       | Pattern match      | High                |
| Special characters (`#`, `@`, `/`)     | Tokenized            | Literal match      | High                |
| Regex                                  | Supported            | Supported          | Medium              |
| Numeric range                          | Supported            | Supported          | Low                 |
| String range                           | Not executed         | Supported          | High                |
| Field exists                           | Supported            | Supported          | Medium              |
| Boost / fuzzy / proximity              | Ignored              | Rejected           | High                |

## Patterns to avoid and recommended alternatives[​](#patterns-to-avoid-and-recommended-alternatives "Direct link to Patterns to avoid and recommended alternatives")

### Wildcards[​](#wildcards "Direct link to 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-patterns "Direct link to 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[​](#numeric-comparisons "Direct link to Numeric comparisons")

Use Lucene range syntax with `.numeric` fields:

```
-- Avoid

event.latency>100



-- Use

event.latency.numeric:[100 TO *]
```

### String ranges[​](#string-ranges "Direct link 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[​](#field-existence-checks "Direct link to 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[​](#boost-fuzzy-and-proximity-operators "Direct link to 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 "Direct link to 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[​](#cidr-ip-matching "Direct link to 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\..*/
```

## Recommended practices[​](#recommended-practices "Direct link to Recommended practices")

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

## Related resources[​](#related-resources "Direct link to Related resources")

[Lucene query builder](https://docs-docusaurus.kinsta.page/user-guides/alerting/lucene-query-builder/.md)[Configure alert definition](https://docs-docusaurus.kinsta.page/user-guides/alerting/configuring-alert-definition/.md)

## Next steps[​](#next-steps "Direct link to Next steps")

Define notification destinations and cadence for your alerts in [Notification settings](https://docs-docusaurus.kinsta.page/user-guides/alerting/configure-notifications/settings/.md).