VictoriaMetrics Error: 'too long query' — Cause, Fix, and Troubleshooting Guide
Fix VictoriaMetrics 'too long query; the maximum allowed query length is -search.maxQueryLen=16384 bytes': collapse or chains to regex, raise the limit.
- #victoriametrics
- #monitoring
- #troubleshooting
- #errors
Fixing errors like this? Get 500 free DevOps AI prompts
500 copy-paste AI prompts for the stack you actually run — one PDF, free.
Overview
VictoriaMetrics rejects any single query whose text exceeds -search.maxQueryLen (default 16384 bytes) before it even tries to execute it. vmselect (or single-node victoria-metrics) returns:
too long query; got 20000 bytes; the maximum allowed query length is -search.maxQueryLen=16384 bytes
This is a request-parser guard, not a resource limit hit during execution. It exists because absurdly long query strings are almost always machine-generated — a template variable that expanded into thousands of values, or a client that built a giant or chain — and such queries are both slow to parse and slow to run. The error fires on the raw byte length of the query expression, so the fix is usually to express the same intent more compactly rather than to raise the ceiling.
Symptoms
- A Grafana panel or Explore query errors with “too long query; … -search.maxQueryLen=16384 bytes”.
- The failing panel uses a multi-value template variable set to “All” over a large value list.
- A programmatic client (alerting, capacity scripts) fails intermittently as its generated selector grows.
- The same logical query works when a variable is scoped down, but fails when broadened across the whole fleet.
- vmselect logs the error at parse time with no corresponding execution or storage activity.
Common Root Causes
- Long
orchains — a query built asexpr1 or expr2 or ... or exprNthat grows unbounded with the number of matched entities. - Grafana variable explosion — a multi-value variable (or several) expanding into thousands of comma-separated values inside one selector.
- Huge regex or literal lists — a programmatic client stitching every id/instance into one enormous label matcher.
- Default limit vs. a legitimately large query — 16384 bytes is plenty for hand-written queries but can be tight for some generated dashboards.
How to diagnose
Measure the actual byte length of the query so you know how far over the limit you are:
# Paste the rendered query expression and count its bytes
printf '%s' '<paste the full expanded query here>' | wc -c
Check the currently configured limit on the running process:
ps aux | grep -E 'vmselect|victoria-metrics' | grep -oE '\-search.maxQueryLen[^ ]*'
In Grafana, open the failing panel’s query inspector and look at the fully interpolated query — the raw text after all $variables are substituted. If it is dominated by a long comma-separated value list or a repeated or pattern, that is your source.
Fixes
1. Collapse or chains into one regex matcher. A long disjunction of label matches becomes a single, far shorter selector:
# Before: a long, brittle or chain
{job="a"} or {job="b"} or {job="c"} or {job="d"}
# After: one regex label matcher
{job=~"a|b|c|d"}
2. Scope Grafana variables so expansion stays small. Chain dropdowns ($cluster -> $job -> $instance) and avoid “All” on high-cardinality variables so the interpolated query never balloons past the limit.
3. Raise the limit when the workload truly needs it. If a legitimate generated query is longer than 16384 bytes and vmselect can handle it, lift the ceiling deliberately:
./vmselect -storageNode=vmstorage-1:8401,vmstorage-2:8401 \
-search.maxQueryLen=65536
Treat this as a last resort — a longer allowed query is slower to parse and usually slower to run.
What to watch out for
- Raising
-search.maxQueryLenhides the real problem (an over-broad panel or client) that will also strain execution and memory — compress the query first, raise the limit second. - Regex matchers (
=~"a|b|c") are dramatically shorter thanorchains and almost always the right rewrite. - A query that squeaks under the length limit today grows as your fleet grows; scope variables so it does not creep back over.
- This guard is about query text length, not result size — a query that returns too many series or points trips different limits, so read the error wording before acting.
Related
- VictoriaMetrics Error Guide: cannot parse MetricsQL
- VictoriaMetrics Error Guide: maxSeries exceeded
- VictoriaMetrics Error Guide: max unique timeseries
Get 500 Battle-Tested DevOps AI Prompts — Free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.