Grafana’s auto-refresh is a surprisingly complex beast that often doesn’t behave quite like you’d expect, primarily because it’s not just about the dashboard itself, but also about the underlying data sources and how they handle repeated queries.
Let’s see it in action. Imagine you have a simple Prometheus data source configured, and you want to see your service’s request rate update every 10 seconds.
# Example Prometheus data source configuration in Grafana
apiVersion: grafana.integreatly.org/v1beta1
kind: GrafanaDataSource
metadata:
name: prometheus-datasource
spec:
datasources:
- name: Prometheus
type: prometheus
access: proxy
isDefault: true
url: http://prometheus.example.com:9090
basicAuth:
user:
name: grafana-user
key: password
jsonData:
httpMethod: GET
timeout: 30
On your Grafana dashboard, you’d add a panel, select your Prometheus data source, and write a query like rate(http_requests_total[5m]). Then, in the top right corner of the dashboard, you’d see the refresh dropdown. You could select "10s".
Now, here’s where it gets interesting. You might expect Grafana to simply re-run that query every 10 seconds. But it’s more nuanced. Grafana will indeed send a new request to Prometheus every 10 seconds. However, Prometheus itself has its own internal data retention and scraping intervals. If Prometheus only scrapes your metrics every 15 seconds, you’re not going to get new data points every 10 seconds; you’ll get the latest available data point, which might be stale from your dashboard’s perspective. The dashboard refresh dictates when Grafana asks for data, not how fresh that data is inherently.
The core problem Grafana’s auto-refresh solves is providing a near real-time view of dynamic system states without manual intervention. It’s the "eyes on the system" for operations teams. Internally, Grafana acts as a client. When you set a refresh interval, it essentially arms a timer. When the timer fires, Grafana iterates through all the panels on the current dashboard, identifies the data source for each, and issues the configured query to that data source. The results are then rendered, updating the visualizations. This process is repeated for every panel, on every refresh.
The levers you control are primarily the refresh interval itself (10s, 30s, 1m, 5m, etc.) and the query’s time range. For instance, if you’re looking at a metric that updates every second, a 10s refresh interval is sensible. If you’re looking at a daily aggregate, refreshing every 5 minutes is overkill. You also need to consider the evaluation_interval in Prometheus (if you’re using it), which dictates how often Prometheus scrapes targets and evaluates rules. If your evaluation_interval is 30 seconds, refreshing your Grafana dashboard every 10 seconds won’t give you fundamentally new data points at that finer granularity.
The most surprising thing most people miss is how Grafana’s "time range" interacts with auto-refresh. When you set an auto-refresh (say, 10s) and have a panel query for rate(http_requests_total[5m]), Grafana isn’t just asking for the last 5 minutes of data from the moment of the refresh. Instead, it’s asking for rate(http_requests_total[5m]) relative to the current dashboard time. If your dashboard’s "time range" is set to "Last 15 minutes", and you refresh every 10 seconds, Grafana will query Prometheus with ...&time_end=<now>&time_start=<now - 15m> for each refresh. The rate() function then calculates the rate over the 5-minute window ending at <now>. This means each refresh essentially slides that 5-minute window forward, giving you a continuously updated view of the rate over the last 5 minutes. If you were to set the dashboard time range to "Last 1 hour", and refresh every 10 seconds, you’d still get the rate over the last 5 minutes, but the historical context displayed would be much larger.
The next common pitfall after getting auto-refresh working is understanding query performance impact, especially with many dashboards refreshing simultaneously.