🚨 VictoriaMetrics Error Guide: 'too many points for the given step and time range' — Increase Step or Raise the Points Limit

Overview

VictoriaMetrics rejects a range query when the number of data points it would need to generate per time series exceeds a safety limit. The error is returned by the query engine and shown in vmui, Grafana, and the raw API:

too many points for the given step=1000 and time range 2678400000; see -search.maxPointsPerTimeseries flag (2678400 points)

The math is simple: points = (end - start) / step. If that value crosses -search.maxPointsPerTimeseries (default 30000), VictoriaMetrics refuses the query rather than allocating an unbounded per-series buffer. It is a guardrail against a query that asks for a 30-day range at a 1-second step, which would produce millions of points per series and exhaust memory. The three ways out are: increase the step, narrow the range, or deliberately raise the limit for a genuine use case.

Symptoms

• A Grafana panel over a long range (30d, 90d) returns too many points while the same panel over 6h renders fine.
• The error appears the moment you zoom out or switch a dashboard’s time picker to a wide window.
• vmui shows the error immediately, before any data is fetched — it is a pre-flight rejection, not a timeout.
• The literal message always names the offending step, the range in milliseconds, and the computed point count.
• Panels with a very small or unset step (e.g. step=1s) fail first, because tiny steps maximize the point count.
• API scripts that build query_range URLs with a fixed small step break as soon as the range grows.

Common Root Causes

• Step too small for the range — a 1s or 10s step over many days multiplies into millions of points per series.
• Range too large — a 90-day query at any modest step can still exceed the default 30000-point cap.
• Grafana $__interval misconfiguration — a panel with a pinned minimum step or a min interval far below the range produces too many points.
• Default -search.maxPointsPerTimeseries too low for the workload — some capacity-planning dashboards legitimately need more points.
• Auto-stepping disabled — clients that hardcode step instead of letting it scale with the range.
• Subqueries with a fine inner resolution — foo[1d:1s] forces 86400 points inside the subquery window per outer step.

Diagnostic Workflow

Confirm the limit currently in force. On single-node VictoriaMetrics (port 8428):

curl -s http://<node>:8428/flags | grep -i maxPointsPerTimeseries

On a cluster the limit is enforced by vmselect (port 8481):

curl -s http://<vmselect>:8481/flags | grep -i maxPointsPerTimeseries

Do the arithmetic the engine does. For a 31-day range with step=1000 (ms), points = 2678400000 / 1000 = 2678400, far above 30000. Reproduce it directly and read the message:

curl -s 'http://<node>:8428/api/v1/query_range' \
  --data-urlencode 'query=node_load1' \
  --data-urlencode 'start=2026-06-08T00:00:00Z' \
  --data-urlencode 'end=2026-07-09T00:00:00Z' \
  --data-urlencode 'step=1s'

Now compute a safe step: to stay under 30000 points over 31 days, step >= 2678400 / 30000 ≈ 90s. Re-run with a larger step and it succeeds:

curl -s 'http://<node>:8428/api/v1/query_range' \
  --data-urlencode 'query=node_load1' \
  --data-urlencode 'start=2026-06-08T00:00:00Z' \
  --data-urlencode 'end=2026-07-09T00:00:00Z' \
  --data-urlencode 'step=120s'

In vmui at http://<node>:8428/vmui/, the “Auto” step control picks a sensible step for the selected range; toggle it to confirm the panel is not pinning an unrealistically small step. In Grafana, check the panel’s “Min interval” and rely on $__interval rather than a hardcoded step.

Check daemon logs to confirm this is a rejection, not a storage problem:

journalctl -u victoriametrics --since '15 min ago' | grep -i 'too many points'

Example Root Cause Analysis

An SRE opened a quarterly capacity dashboard and every panel returned too many points for the given step=1000 and time range 7776000000. Shorter dashboards worked.

The message did the diagnosis: a 90-day range (7776000000 ms) at step=1000 ms is 7,776,000 points per series — 259x the default 30000 cap. Inspecting the Grafana panel showed a “Min interval” of 1s left over from a debugging session, which pinned $__interval to 1s regardless of range. Because the panel also plotted rate(...) across dozens of series, the request would have tried to materialize hundreds of millions of points.

The team removed the pinned min interval so $__interval scaled with the range (Grafana chose ~30m for 90 days, well under the cap). For a couple of genuinely high-resolution capacity panels that needed finer granularity, they raised -search.maxPointsPerTimeseries to 100000 on vmselect after confirming vmselect had enough RAM headroom. The quarterly dashboard rendered without touching the raw storage load.

Prevention Best Practices

• Let clients auto-scale step with the range: use Grafana’s $__interval and avoid pinning “Min interval” to tiny values.
• When scripting query_range, compute step = ceil((end - start) / maxPoints) so the request always fits the limit.
• Raise -search.maxPointsPerTimeseries only for specific high-resolution dashboards, and verify vmselect memory headroom first — each extra point costs per-series RAM.
• Prefer recording rules for long-range panels so you query a pre-aggregated, coarse series instead of raw high-resolution data.
• Educate dashboard authors that a wide time picker needs a coarse step; fine-grained detail belongs in short-range views.
• Keep an eye on process_resident_memory_bytes on vmselect after raising the limit, since large point buffers drive memory use.

Quick Command Reference

# Show the current points-per-timeseries limit
curl -s http://<node>:8428/flags | grep -i maxPointsPerTimeseries      # single-node
curl -s http://<vmselect>:8481/flags | grep -i maxPointsPerTimeseries  # cluster

# points = (end - start) / step  -> keep below the limit (default 30000)
# Safe step for a range R (ms) and cap C: step >= R / C

# Reproduce with a small step (fails), then a larger step (succeeds)
curl -s 'http://<node>:8428/api/v1/query_range' \
  --data-urlencode 'query=node_load1' \
  --data-urlencode 'start=...' --data-urlencode 'end=...' --data-urlencode 'step=120s'

# Confirm it is a rejection, not a timeout
journalctl -u victoriametrics --since '15 min ago' | grep -i 'too many points'

# Raise the limit only when justified (flag on single-node or vmselect)
-search.maxPointsPerTimeseries=100000

Conclusion

too many points for the given step ... see -search.maxPointsPerTimeseries flag is a deliberate guardrail, not a bug. The literal message hands you the arithmetic: divide the range by the step and compare against the limit. In almost every case the right fix is to increase the step (or let Grafana’s $__interval do it) or narrow the range, so the query returns a reasonable number of points. Reserve raising -search.maxPointsPerTimeseries for genuine high-resolution needs, and only after confirming vmselect has the memory to hold the larger buffers. For recurring long-range views, pre-aggregate with recording rules and the problem disappears entirely.