🚨 Grafana Error Guide: 'the query time range exceeds the limit' — Loki max_query_length and lookback

Overview

When you point a Grafana panel at a Loki datasource and pick a wide time range, the query can be rejected before Loki ever scans a single chunk. Grafana surfaces the failure straight from Loki’s query-frontend:

the query time range exceeds the limit (query length: 800h0m0s, limit: 721h0m0s)

You may also see closely related variants depending on the limit that tripped:

the query would read too far back
invalid max_query_lookback

Loki enforces two distinct guardrails. max_query_length caps the width of a single query (default 721h, roughly 30 days). max_query_lookback caps how far back in time you may query at all, and is usually pinned to your retention window. A dashboard set to “Last 60 days” trips the first; a panel asking for data older than retention trips the second. Neither is a bug in Loki — they are protective limits in limits_config.

Symptoms

• A Loki panel shows a red error banner: the query time range exceeds the limit.
• The same query works on “Last 6 hours” but fails on “Last 30 days” or wider.
• Explore returns the error instantly (no chunk scan latency) — a sign it is a limit check, not a timeout.
• Logs older than your retention period return empty or the query would read too far back.
• query length in the message is larger than the limit value.

Common Root Causes

1. Dashboard time range wider than max_query_length

The most common cause: the time picker (or a $__range-based panel) spans more than max_query_length.

# loki limits_config (loki.yaml)
limits_config:
  max_query_length: 721h   # ~30 days (default)
  max_query_lookback: 744h
  query_timeout: 300s

level=warn caller=metrics.go msg="query rejected"
  err="the query time range exceeds the limit (query length: 800h0m0s, limit: 721h0m0s)"
  org_id=fake

An 800h (≈33 day) range exceeds the 721h cap. Either narrow the range or raise the limit.

2. Querying beyond retention (max_query_lookback)

max_query_lookback should track retention_period. If lookback is longer than data you actually keep, users get empty results; if a query start time is older than lookback, Loki rejects it.

limits_config:
  retention_period: 744h        # compactor deletes after 31d
  max_query_lookback: 744h      # align with retention
compactor:
  retention_enabled: true
  compaction_interval: 10m

level=info msg="the query would read too far back"
  lookback=744h requested_start="2026-05-01T00:00:00Z"

3. split_queries_by_interval magnifying the range

The query-frontend splits a long query into per-interval subqueries. The total span is still measured against max_query_length, so splitting does not exempt you.

query_range:
  split_queries_by_interval: 24h
  parallelise_shardable_queries: true

caller=roundtrip.go msg="split query" original_range=800h split_interval=24h
  err="the query time range exceeds the limit"

Diagnostic Workflow

Step 1 — Confirm the exact limit that tripped. Read the message: query length: 800h vs limit: 721h points at max_query_length; read too far back points at max_query_lookback.

Step 2 — Reproduce with a raw range query so you isolate Loki from Grafana:

curl -sG 'http://loki:3100/loki/api/v1/query_range' \
  --data-urlencode 'query={app="checkout"} |= "error"' \
  --data-urlencode "start=$(date -d '-40 days' +%s)000000000" \
  --data-urlencode "end=$(date +%s)000000000" \
  --data-urlencode 'limit=100' | jq '.status,.error'

Step 3 — Inspect the effective limits Loki is running with:

curl -s http://loki:3100/config | grep -A6 limits_config
curl -s http://loki:3100/config | grep -E 'max_query_length|max_query_lookback|retention_period'

Step 4 — Check the Loki logs for the rejection:

kubectl logs deploy/loki -n loki | grep -i "exceeds the limit"
journalctl -u loki -n 200 --no-pager | grep -i lookback

Step 5 — Test a narrower LogQL query in Grafana Explore to confirm the pipeline works within limits:

{app="checkout", namespace="prod"} |= "error" | logfmt | status >= 500

Example Root Cause Analysis

An on-call engineer builds a “Monthly Error Trends” dashboard and sets the time picker to “Last 45 days”. Every Loki panel returns the query time range exceeds the limit (query length: 1080h0m0s, limit: 721h0m0s) instantly.

Reading the message, query length: 1080h (45 days) is clearly above the default max_query_length: 721h. The team confirms with curl http://loki:3100/config that the limit is the default. They have 60 days of retention, so the data exists — the query is simply wider than one call is allowed to be.

Two fixes apply. For the dashboard, they cap the panel with a relative range and use recording rules for long-horizon trends. For legitimately long queries they raise the per-tenant limit in the overrides file:

overrides:
  observability-team:
    max_query_length: 1464h   # 61 days
    max_query_lookback: 1464h

After a config reload the panels render. The lesson: raise the limit deliberately per-tenant rather than globally, and prefer recording rules over month-wide raw scans.

Prevention Best Practices

• Keep default dashboard ranges tight (6h–24h) and expose a template variable for wider views.
• Set max_query_lookback equal to retention_period so users never query data that has been compacted away.
• Raise max_query_length only in per-tenant overrides, not globally, to avoid cluster-wide load.
• Use recording rules / metric queries for long-horizon trend panels instead of raw log scans.
• Tune split_queries_by_interval and query_timeout together so large-but-legal queries actually finish.
• Document your retention and query limits alongside the datasource in the Grafana category guides.

Quick Command Reference

# Effective limits Loki is running
curl -s http://loki:3100/config | grep -E 'max_query_length|max_query_lookback|retention_period'

# Reproduce a wide range query outside Grafana
curl -sG 'http://loki:3100/loki/api/v1/query_range' \
  --data-urlencode 'query={app="checkout"}' \
  --data-urlencode "start=$(date -d '-40 days' +%s)000000000" \
  --data-urlencode "end=$(date +%s)000000000" | jq '.error'

# Find rejections in logs
kubectl logs deploy/loki -n loki | grep -i "exceeds the limit"
journalctl -u loki -n 200 --no-pager | grep -i lookback

# Verify Loki is healthy
curl -s http://loki:3100/ready

Conclusion

Top root causes, in order of likelihood:

1. Dashboard time range wider than max_query_length (default 721h / ~30 days) — narrow the picker or raise the per-tenant limit.
2. Querying beyond max_query_lookback / retention — align lookback with retention_period and the compactor.
3. Long queries split by split_queries_by_interval still measured as one total span — total width, not subquery width, is what counts.
4. Global limits set too low for a specific team — use overrides per tenant instead of loosening the whole cluster.