Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for Victoria Metrics By James Joyner IV · · 7 min read

VictoriaMetrics Error: 'too long query' — Cause, Fix, and Troubleshooting Guide

Quick answer

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
Free toolkit

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 or chains — a query built as expr1 or expr2 or ... or exprN that 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.maxQueryLen hides 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 than or chains 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.
Free download · 368-page PDF

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.