Open in ChatGPTOpen in Claude

Errors and warnings

When you run a query in Explore, Coralogix tells you whether it ran cleanly. Two outcomes need your attention:

• Error: the query fails and returns no results.
• Warning: the query succeeds and returns results, along with advisories about how it ran.

Errors and warnings work the same way whether you explore Logs or Spans, and whether you query in Builder or DataPrime. Explore shows an error in red and a warning in yellow, with the message so you can resolve it.

Errors

An error means the query can't run, so Explore returns no results. Correct the cause and run the query again. Common causes:

• Invalid query syntax: Explore can't compile the Builder configuration or DataPrime expression. The message identifies the problem so you can correct the flagged part. For example:
  • DataPrime: Unexpected token 'and' at position 42
  • Builder: Filter value required for field "status"
• Query timeout: the query ran too long to return results. Narrow the time range or make the query more selective.
• Rate limit reached: too many queries ran in a short period. Wait a moment, then run the query again.
• Resources exhausted: the query compiled but needed more memory or compute than allowed, typically from high-cardinality aggregations or wide field selections. Reduce the number of fields, aggregation buckets, or the time range.

Type errors in DataPrime queries

Early access

The improved type analysis described here is rolling out per environment, so the message you see depends on which environment your team is in. Queries behave the same either way, only the wording of the error changes. It isn't available on govprod.

DataPrime checks the types of every expression in a query before it runs, and rejects a query that compares, combines, or passes values of types that don't fit together. The error names the mismatch and traces each side back to where it came from, so you can see which part of the query to correct.

Take a query that compares a number with a string:

source logs
| create 1 as a
| create 'foo' as b
| filter a == b

type mismatch - got string, expected number
    number is expected by type parameter T, expanded to number of ==
    string comes from:
        keypath at b
        expression at 'foo'

Read it from the bottom up. The string originates in the literal 'foo', which reaches the comparison through the field b. The == operator has already been fixed to number by its other side, a. Correcting either side resolves the error: quote a, convert b with a cast, or compare the fields you actually meant to compare.

In Explore, the message appears under the line it flags, and the part that traces the mismatch back to its source expands and collapses. Hover a highlighted value in the message to see the part of the query it refers to, and copy the whole message with the copy button in its top-right corner when you want to paste it into a ticket or hand it to an agent. The query APIs return the same trace as a list of ranges instead of this expandable UI.

Any error that originates earlier in the query is traced this way, not only comparisons.

Warnings

A warning means the query ran and returned results, but something about how it ran is worth knowing. The results shown are valid for what Explore was able to return. Common warnings:

• Partial results: the query reached a result or scan limit, such as a row cap or an aggregation-bucket cap, so the results are a subset. Narrow the query or time range to see the full picture.
• No data available: the query is valid, but no data matches for the selected time range. Adjust the query or widen the time range.
• Missing fields: a field referenced in the query doesn't exist in the schema of the queried dataset. Check the field path for typos, or confirm the field exists in this dataset. A field that exists but has no matching values is different: the Fields Panel shows "No values found" for it, and no warning appears.
• Unindexed fields read from raw data: the query reads fields that aren't indexed, which might slow it down. Reserve those fields to speed up future queries.

Speed up queries that read unindexed fields

Coralogix indexes fields as it ingests them. When a query references a field that isn't indexed, Coralogix reads it from the raw event data, which might slow the query down. Explore then surfaces a performance warning that names the affected datasets and fields and points you to reserve them.

Unindexed-fields warning

Performance warning: the following fields were not indexed in some of the files queried, so some entries required raw data parsing:

default/logs : host.name

To avoid this, ask a team admin to reserve these fields in Schema Manager.

To clear the warning, reserve the listed fields so Coralogix maps them on ingestion and future queries read them from the index. Reserving fields requires manage access, so ask a team admin to reserve them in Schema Manager.

A team admin reserves the fields as follows:

1. Open Schema Manager.
2. Select the dataspace and dataset named in the warning.
3. Open Reserved fields.
4. Add the fields listed in the warning to the reserved list.

Reserved fields apply to newly ingested data, so the warning clears for later queries over that data. For details, see Adding reserved fields.

Why a field isn't indexed

Coralogix writes your data in files that hold each record in full alongside a separate column per field. When a query filters, groups, or compares on a field that has a column, it reads that column directly, which is fast.

A file holds roughly 5,000 columns. If a dataset has fewer distinct fields than that, every field gets a column and every query takes the fast path. Past that point some fields don't get one. They're still recorded in the file and still queryable, and results stay correct, but the query has to open each record and pull the value out of the raw data, which is the slow path the warning reports.

Two things follow:

• Keep a dataset's field count under about 5,000 for the best query performance. Splitting noisy, high-cardinality data into its own dataset keeps the field count of the datasets you query most within the limit. See Dataspaces and datasets.
• Reserving a field is how you guarantee it gets a column. Fields you haven't reserved compete for the remaining slots, and which ones win is decided for you, from how often each field appears in the data being written. A field that shows up in nearly every record is kept even if nobody queries it, so a field you query constantly can lose its column to one you never touch. Reserving it takes it out of that competition.

There's nothing to configure beyond reserving fields, and no way to see which fields hold a column in a given file. Treat the warning as the signal: if it names a field you query often, reserve it.

Note

Custom Dashboards raises the same warning on a widget query that reads unindexed fields, in older wording: it reports that the query's fields had to be read from the raw event data, which might impact query performance. The cause and the fix are the same, so reserve the fields as described above.

Related resources

• Reserved fields. Reserve the fields a query reads from raw data.
• Schema management, discover and govern the structure of your ingested data.
• Overview tab, where query warnings surface alongside the results chart.

Next steps

Copy, share, and open records in context with Explore actions.