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

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

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

```text
-- 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

```text
user.name.keyword:/.*@example\.org/
```

### Numeric comparisons

Use Lucene range syntax with `.numeric` fields:

```text
-- 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:

```text
-- 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:

```text
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:

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

Always escape special characters such as dashes:

```text
status:"pre\-production"
```

### CIDR IP matching

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

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

## Recommended practices

Follow these guidelines to create reliable alert queries:

1. Use simple terms and boolean operators
1. Replace wildcards with regex
1. Use `.keyword` for regex and `.numeric` for numeric ranges
1. Make regex anchors explicit
1. Avoid boost, fuzzy, and proximity operators
1. Avoid string range queries
1. Scope queries with field names when using special characters
1. Use regex for exact matching with special characters
1. Escape special characters consistently
1. 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/) [Configure alert definition](https://coralogix.com/docs/user-guides/alerting/configuring-alert-definition/)

## Next steps

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