---
title: Alert query behavior
description: Understand how Lucene queries behave differently in real-time alert evaluation compared to the archived data shown in Case and Incident views. Learn which query patterns to avoid and how to write reliable alert queries.
url: https://coralogix.com/docs/user-guides/alerting/lucene-query-builder/query-behavior/
product: alerts
feature: Alert Definitions
feature_id: alert-definitions
feature_identifier: alerts/alert-definitions
last_updated: '2026-09-03'
---

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

## 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 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

What `.keyword` means

A string field is indexed two ways. The base field (for example, `msg`) is *analyzed*: its value is broken into lowercase tokens, so a query matches individual words inside it. The `.keyword` variant (`msg.keyword`) keeps the whole value as a single exact, un-tokenized string. Regex, wildcards, and special-character matching need this raw value to behave consistently, which is why the recommendations below target the `.keyword` form. The `.numeric` suffix works the same way for numeric range comparisons.

### 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\..*/
```

## 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

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

## Next steps

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