🚨 Prometheus Error Guide: 'exceeded maximum resolution of 11000 points per timeseries' Range Query Resolution

Exact Error Message

This error comes back from the Prometheus HTTP API on a query_range request and surfaces in Grafana panels as a red banner:

exceeded maximum resolution of 11000 points per timeseries. Try decreasing the query resolution (?step=XX)

In a raw API response it looks like this:

{"status":"error","errorType":"bad_data","error":"exceeded maximum resolution of 11000 points per timeseries. Try decreasing the query resolution (?step=XX)"}

The HTTP status is 400 Bad Request. Nothing is dropped at ingestion and no data is missing — the query is simply rejected before evaluation.

What the Error Means

A range query (/api/v1/query_range) evaluates an expression at evenly spaced points across a time window. The number of points it must produce per series is:

points = (end - start) / step

Prometheus refuses to evaluate any range query where this count exceeds 11000 points per timeseries. The limit is hard-coded in the API handler (the query_range resolution guard) and is not configurable via a flag. It exists to stop a single panel from forcing the engine to evaluate hundreds of thousands of points and to keep response payloads bounded.

The phrase “decreasing the query resolution” is slightly counterintuitive: you decrease resolution by increasing step (fewer, more widely spaced points). A 30-day window (2,592,000 s) at a 60 s step is 43,200 points — almost four times the cap, so it is rejected immediately.

Common Causes

• A small step over a large range. The classic case: start/end 7–90 days apart with a step of 15 s, 30 s, or 60 s. Any window/step combination above 11000 points fails.
• Grafana max data points / min interval misconfigured. Grafana computes step from the panel’s pixel width and “Max data points”. If a dashboard variable widens the time range but the min interval is left at the default, the computed step shrinks and trips the cap.
• $__interval too small. A query using rate(metric[$__interval]) with $__interval driven by a wide range and no min step produces a tiny step value.
• API misuse in scripts. Custom exporters, capacity reports, or Slack bots that call query_range with a hard-coded step=15 regardless of the requested range.
• Dashboards copied between environments. A panel built for a 1-hour view reused on a 30-day “executive overview” without adjusting the step.

How to Reproduce the Error

Issue a query_range whose point count exceeds 11000. With a 30-day window and a 60 s step:

END=$(date +%s)
START=$(( END - 30*24*3600 ))   # 30 days
curl -s "http://localhost:9090/api/v1/query_range" \
  --data-urlencode 'query=up' \
  --data-urlencode "start=$START" \
  --data-urlencode "end=$END" \
  --data-urlencode 'step=60' | jq -r '.error'

exceeded maximum resolution of 11000 points per timeseries. Try decreasing the query resolution (?step=XX)

Here points = 2592000 / 60 = 43200, well over the cap. Raise step to 300 (8640 points) and the same query succeeds.

Diagnostic Commands

Compute the point count for any window/step before you send it:

START=1716000000; END=1718592000; STEP=15
echo "points = $(( (END - START) / STEP ))   (cap = 11000)"

points = 172800   (cap = 11000)

Find the minimum step that stays under the cap for a given range:

RANGE=$(( 30*24*3600 ))
echo "min step = $(( RANGE / 11000 + 1 )) s"

min step = 236 s

Inspect exactly what Grafana sent by replaying the failing panel query against the API and reading the step query parameter from the Grafana panel’s query inspector (Panel → Inspect → Query). The step field there is the value to grow.

Check TSDB scrape interval so your step is never finer than the data resolution (a 15 s step over 60 s scrape data wastes points):

curl -s http://localhost:9090/api/v1/status/tsdb | jq '.data.headStats'
grep -nE 'scrape_interval' /etc/prometheus/prometheus.yml

Confirm the running version and that the limit is in force:

journalctl -u prometheus --no-pager | grep -iE 'maximum resolution|11000' | tail

Step-by-Step Resolution

1. Increase the step. For ad-hoc API calls, set step to at least range / 11000, rounded up. Prefer a step that is a clean multiple of your scrape interval (e.g. 300 s for 60 s scrapes):

curl -s "http://localhost:9090/api/v1/query_range" \
  --data-urlencode 'query=up' \
  --data-urlencode "start=$START" --data-urlencode "end=$END" \
  --data-urlencode 'step=300' | jq '.status'

2. Set a Grafana minimum interval. On the panel: Query options → Min interval = 1m (or higher for wide dashboards). This floors the computed step so Grafana never sends a sub-minute step on a multi-week range. Set Max data points to ~1000–1500 rather than the pixel width.

3. Use a dashboard min-step variable. For range-driven dashboards, gate the step with $__rate_interval instead of $__interval in rate()/increase(); it already respects the panel min interval and scrape interval.

4. Pre-aggregate with recording rules. For wide views, evaluate the heavy expression once per interval and query the cheap recorded series:

groups:
  - name: capacity
    interval: 1m
    rules:
      - record: job:http_requests:rate5m
        expr: sum by (job) (rate(http_requests_total[5m]))

Dashboards then query job:http_requests:rate5m at a coarse step over months without hitting the cap.

5. Reduce the range when high resolution is genuinely needed — show 24 h at 15 s rather than 30 d at 15 s, and let users zoom.

Prevention and Best Practices

• Standardise a min interval of 1m on long-range dashboards and 30s on operational ones; document the rule in your Grafana provisioning.
• Never hard-code step=15 in scripts. Derive it: step = max(scrape_interval, ceil(range/10000)), leaving headroom below 11000.
• Build “overview” panels on recording rules so a quarter of data is a few thousand points, not millions.
• Keep step a multiple of scrape_interval; finer steps add points without adding information.
• Long-range, slow queries that do fit under the cap can still time out — see Prometheus ‘query timed out’ / ‘too many samples’ for the sample-count and timeout side of wide queries.

Related Errors

• query timed out / query processing would load too many samples — the wide-query problem when the query is under 11000 points but still touches too much data. See the dedicated guide.
• expanding series: context deadline exceeded — the same wide-range query exceeding the configured query timeout.
• invalid parameter "step": ... — a malformed or zero step, returned as bad_data like this error but for a different reason.

Frequently Asked Questions

Can I raise the 11000-point limit with a flag? No. Unlike the query timeout or max-samples limits, the 11000-points-per-timeseries cap is hard-coded in the query_range API handler and has no flag. The intended fix is always to increase step, narrow the range, or pre-aggregate.

Why does the error say “decrease resolution” when I need a bigger step? “Resolution” here means data points per series. Increasing step produces fewer points, i.e. lower resolution. It is the same action — a larger step value — described from the resolution side.

My Grafana panel works on 6 hours but fails on 30 days. Why? Grafana scales step with the time range to keep roughly constant on-screen density, but past a point the range grows faster than the step and the point count crosses 11000. A Min interval floor plus a sane Max data points value prevents this.

Does this mean I’m losing data? No. This is a pre-evaluation guard; ingestion and storage are untouched. The query is rejected before it runs, so you just need to ask for it at a coarser step.

What step should a 90-day dashboard use? 90*24*3600 / 11000 ≈ 707 s is the minimum. Use 900s (15 m) or 1h for comfortable headroom, ideally backed by a recording rule evaluated every 1–5 minutes.