🚨 Loki Error Guide: 'parse error: syntax error: unexpected IDENTIFIER' — Fix Invalid LogQL

Overview

Loki rejects a query it cannot parse before executing anything. Grafana and logcli show a message pointing at the offending position:

parse error at line 1, col 25: syntax error: unexpected IDENTIFIER, expecting STRING

Common variants include unexpected }, unexpected RANGE, unexpected =, and queries require at least one regexp or equality matcher. LogQL has a strict grammar: a stream selector in {}, optional line/label filters, an optional pipeline, and — for metric queries — a range aggregation wrapping a log query. A mismatch anywhere produces this error.

Symptoms

• The query never runs; the error appears immediately with a line/column pointer.
• Small syntax edits (a quote, a brace, an operator) flip the query between working and failing.
• Copy-pasted queries from PromQL or other tools fail because LogQL differs.
• Grafana template-variable expansion produces invalid text (e.g. empty or unquoted values).
• logcli prints the parse error before streaming any results.

Common Root Causes

• Unquoted label values — {app=checkout} instead of {app="checkout"}.
• Missing/empty stream selector — a metric query without a valid {...} selector, or an all-negative matcher.
• PromQL habits — using =~ on a metric like PromQL, or wrapping with functions that don’t exist in LogQL.
• Misplaced pipeline stages — a parser or label filter before the stream selector, or a line filter after a metric aggregation.
• Bad range syntax — rate({...} [5m]) written as rate({...}, 5m) or a missing [range].
• Template variables — a Grafana variable expanding to empty/unquoted text, breaking the grammar at query time.

Diagnostic Workflow

Read the column pointer — it names the exact position and what token was expected:

parse error at line 1, col 25: syntax error: unexpected IDENTIFIER, expecting STRING

Quote label values in the stream selector:

# Wrong
{app=checkout, level=error}
# Right
{app="checkout", level="error"}

Keep the pipeline order: selector, then line filters, then parser, then label filters:

{app="checkout"} |= "timeout" | json | status_code >= 500

For metric queries, wrap a log query in a range aggregation with a [range]:

# Wrong
rate({app="checkout"} |= "error", 5m)
# Right
sum by (level) (rate({app="checkout"} |= "error" [5m]))

Validate a query from the CLI before wiring it into a dashboard:

logcli query '{app="checkout"} |= "timeout" | json | status_code >= 500' \
  --since=15m --limit=20

Debug a Grafana template-variable expansion by printing the interpolated query (Query Inspector) and ensuring variables are quoted, e.g. {app="$app"} with a non-empty value.

Example Root Cause Analysis

A dashboard panel intermittently failed with parse error at line 1, col 12: syntax error: unexpected }, expecting STRING. The panel used {app="$service"} where $service was a Grafana template variable. When a user selected the “All” option, the variable expanded to an empty string, producing {app=""} — and in a metric-query context with no other matcher, Loki treated it as having no valid equality matcher, tripping the parser.

The fix had two parts. They set the template variable’s “All” value to a regex that matches everything meaningful and switched the matcher to {app=~"$service"} so an all-selection expanded to a valid non-empty regex rather than an empty equality. They also added a second low-cardinality anchor matcher ({namespace="prod", app=~"$service"}) so the selector always had at least one concrete equality matcher. After that, every variable state produced valid LogQL, and the Query Inspector confirmed the interpolated query parsed cleanly — the bug was in variable expansion, not the base query.

Prevention Best Practices

• Always quote label values in stream selectors: {key="value"}.
• Remember LogQL order: stream selector, line filters, parser, label filters; range aggregations wrap the whole log query with a [range].
• Don’t port PromQL verbatim — LogQL functions and matcher rules differ.
• Quote Grafana template variables ({app="$app"} or =~"$app") and set sensible “All”/empty values so expansion never yields invalid syntax.
• Validate queries with logcli before embedding them in dashboards or alerts.
• Ensure every selector has at least one equality or regex matcher; all-negative selectors are rejected.

Quick Command Reference

# Validate a log query
logcli query '{app="checkout"} |= "timeout" | json | status_code >= 500' --since=15m --limit=20

# Validate a metric query
logcli query 'sum by (level) (rate({app="checkout"} |= "error"[5m]))' --since=15m

# Common corrections
# {app=checkout}                -> {app="checkout"}
# rate({...}, 5m)               -> rate({...}[5m])
# filter before selector        -> selector first, then | filters

Conclusion

parse error: syntax error: unexpected IDENTIFIER (and its variants) means the query violates LogQL’s grammar before execution — most often unquoted label values, PromQL habits, misordered pipeline stages, a missing [range], or a Grafana variable expanding to invalid text. Read the column pointer, quote your label values, keep the selector-filter-parser-label-filter order, and wrap metric queries in a range aggregation. Validate with logcli and quote template variables so dynamic dashboards always produce parseable LogQL.