Grafana Interview Questions (2026): Most Asked, With Answers

Grafana is an open source visualization and observability platform. It connects to data sources, time-series databases like Prometheus, log stores like Loki, tracing backends like Tempo, plus SQL databases, cloud provider APIs, and dozens of other integrations, and turns whatever data lives there into dashboards, ad-hoc exploration, and alerts. The problem it solves is consolidation: instead of jumping between five different vendor UIs to understand one incident, a team builds one dashboard that pulls metrics, logs, and traces into a single pane.

The distinction worth stating clearly in an interview is that Grafana is not a database. It has no built-in long-term storage for metrics or logs by default. It queries whatever you point it at, at read time, and renders the result. That's why a Grafana outage rarely means you lost data, it means you lost your view into data that's still sitting safely in Prometheus or Loki.

Grafana OSS is the free, self-hosted, open source core. Grafana Enterprise is a paid, self-hosted tier layered on top of OSS that adds enterprise data source plugins, more granular RBAC, reporting, and support contracts. Grafana Cloud is the fully hosted, managed offering, Grafana itself plus hosted Mimir (metrics), Loki (logs), and Tempo (traces) run and scaled by Grafana Labs, so you skip the operational overhead of running the storage backends yourself.

A common follow-up is why a team would pick self-hosted OSS over Cloud. Data residency requirements, existing infrastructure investment, or wanting full control over upgrade timing are the usual answers. Cloud wins when a team doesn't want to own Prometheus federation, Loki storage tiering, or Grafana's own database as an ops burden.

Time-series metrics: Prometheus, Graphite, InfluxDB. Logs: Loki, Elasticsearch. Traces: Tempo, Jaeger, Zipkin. Relational: MySQL, PostgreSQL. Cloud-native: CloudWatch, Azure Monitor, Google Cloud Monitoring. Each data source ships its own query editor inside Grafana, PromQL for Prometheus, LogQL for Loki, TraceQL for Tempo, because the underlying query language is owned by the data source, not by Grafana itself.

A dashboard is a JSON document that describes a set of panels, their positions on a grid, the queries feeding each panel, template variables, time range defaults, and annotations. The UI is a friendly editor over that JSON, but the JSON is the actual source of truth, which is exactly why dashboards can be version-controlled, exported, imported, or provisioned from files or Git.

{
 "title": "API Latency",
 "panels": [
  { "type": "timeseries", "title": "p99 latency", "targets": [ { "expr": "histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))" } ] }
 ],
 "templating": { "list": [ { "name": "env", "type": "custom" } ] }
}

A panel is a single visualization inside a dashboard, one query result rendered one way. The common types are time series (a line or area graph over time), stat (a single big number), gauge, bar chart, table, heatmap, logs (for Loki/Elasticsearch results), and node graph or trace view for tracing data. Each panel type has its own field configuration for units, thresholds, and color mapping, independent of the query behind it.

Explore is Grafana's ad-hoc query workspace. It lets you run a query against any data source, tweak it, and see results immediately without saving a panel or building a dashboard first. It's built for incident response and debugging, split-screen comparison of two queries or two time ranges, log line drill-down, and jumping from a metric spike straight into the logs for that same time window are all Explore-native workflows. A dashboard is for a stable, repeatable view. Explore is for the question you didn't know you'd need to ask until five minutes ago.

An annotation is a marker on a graph tied to a specific point or range in time, usually rendered as a vertical line with a tooltip. Deployments, incidents, and config changes are the classic use cases: mark the moment a deploy went out, and every panel on the dashboard shows that same vertical line, so a latency spike five minutes later is trivially easy to correlate back to the release.

A dashboard exports and imports as JSON, the same JSON model that Grafana stores internally. The numeric IDs referenced in blog posts and docs, "import dashboard 1860," point to community dashboards published on Grafana's own dashboard library, grafana.com/grafana/dashboards, and importing by ID just pulls that published JSON down and lets you map its expected data source onto whichever one you actually have configured.

A data link attaches a clickable action to a panel or a specific field's value, a URL to an external runbook, or a jump into Explore pre-filtered to that exact data point's time range and labels. It's the mechanism behind the metric-to-trace and metric-to-log jumps mentioned elsewhere on this page, clicking a spike on a graph and landing directly in the relevant logs is a data link doing the work beneath that.

A stat panel shows a single number, big and simple, usually with a sparkline and a color threshold behind it. A gauge panel shows that same single number as a needle or arc against a defined min and max, making it visually obvious how close a value is to a ceiling, disk usage against total capacity, for instance, in a way a bare number doesn't communicate as quickly at a glance.

A template variable is a placeholder, like $env or $instance, that a dashboard viewer can change from a dropdown at the top of the page, and that value gets substituted into every panel's query that references it. Instead of building one dashboard per environment or per server, you build one dashboard and let the variable pick which environment or server it's currently pointed at.

up{job="api", environment="$env"}

Grafana ships with SQLite as its default internal database out of the box, storing users, dashboards, and settings. It's fine for a local trial or a small single-instance setup. Anything running in production, especially with more than one Grafana instance for high availability, needs to point at a real external database, MySQL or PostgreSQL, since SQLite is a single-file, single-writer database that doesn't support multiple Grafana instances sharing state safely.

A contact point is a destination, Slack channel, PagerDuty integration, email address, webhook, that an alert notification actually gets sent to. A notification policy is the routing logic that decides which contact point a given firing alert should go to, based on the alert's labels, team = payments routes to the payments Slack channel, severity = critical also pages PagerDuty, and so on. The contact point is the "where." The notification policy is the "which alert goes where, and does it also escalate."

A Viewer can see dashboards and change the top-level filters like time range and template variables, but can't save changes to a panel or create new dashboards. An Editor can build and modify dashboards, add panels, and change queries. The friction usually shows up when someone with Editor access on a shared dashboard makes a quick change during an incident, adjusting a threshold or adding a panel, and forgets to communicate it, so the next person to load that dashboard sees something different than they expected with no record of who changed it or why.

Data source plugins add support for querying a new backend that Grafana doesn't support out of the box. Panel plugins add a new visualization type beyond the built-in ones. App plugins bundle multiple panels, pages, and sometimes their own data sources into a cohesive add-on experience inside Grafana, effectively a mini-application living inside the platform. Hundreds of each type exist in Grafana's official plugin catalog, built by both Grafana Labs and the community.

A library panel is defined once and then referenced from multiple dashboards, so editing the library panel's query or visualization updates every dashboard that references it at the same time. A normal panel copied and pasted across dashboards is an independent snapshot the moment you paste it, editing one copy does nothing to the others, which is exactly how teams end up with five slightly-diverged versions of the same "error rate" panel scattered across different dashboards.

Query variables pull their possible values from a live query against a data source, list every Kubernetes namespace, say. Custom variables are a fixed, manually typed list you define once. Text box variables accept free-form input from the viewer. Constant variables hold a single fixed value, usually used to keep a magic number out of every query in one place. Data source variables let a viewer switch which data source instance a panel queries against, useful for multi-region setups. Interval variables control a time-bucket size like $__interval for grouping aggregation windows. Ad hoc filter variables apply free-form key-value filtering across every query on the dashboard for data sources that support it, without needing to predefine the filter keys (Grafana documentation, Template variables).

A chained variable is a query variable whose own query references another variable, so selecting a value in the first variable narrows the choices available in the second. A common real example: pick a Kubernetes cluster in variable one, and variable two's query for namespace filters down to only namespaces that exist in that cluster.

label_values(kube_namespace_labels{cluster="$cluster"}, namespace)

It breaks most often when the child variable's query doesn't actually reference the parent variable correctly, so it silently returns every value from every cluster instead of a filtered list, and nobody notices until someone picks a cluster/namespace combination that doesn't actually exist together.

Set a panel or a row to repeat by a multi-value variable, and Grafana generates one copy of that panel per selected value automatically, one CPU graph per selected host, for example, instead of you manually duplicating the panel for every host and hardcoding each one. The catch is that repeated panels only lay out cleanly in one direction (horizontally or vertically) at a time, and if the variable's selected values change dramatically in count, dashboard layout can shift in ways that are hard to predict from the editor alone. It's also easy to accidentally repeat a heavy query across dozens of values and quietly overload the data source.

A transformation reshapes the data Grafana already got back from a query, after the fact, inside Grafana itself, rather than changing what's asked of the data source. Merging results from two separate queries into one table, renaming a field, doing arithmetic between two series, or filtering rows by a value are all transformations. The query decides what data comes back. The transformation decides how that already-returned data gets reshaped before it's rendered.

The dashboard time range is the shared window every panel uses by default, the last 6 hours, last 24 hours, whatever's selected in the top-right picker. A panel-level time range override lets one specific panel ignore that shared window and always show its own fixed or relative range instead, a weekly summary stat next to a live 15-minute graph on the same dashboard, for instance. It's a small feature, but interviewers use it to check whether a candidate has actually built a dashboard with mixed granularity, not just single-purpose ones.

$__interval is Grafana's automatically calculated grouping window, sized based on the panel's width and the currently selected time range, so a query aggregating by time bucket stays readable whether someone's looking at the last hour or the last 30 days. $__range is the total selected time span itself, start to end, useful when a query needs to know the overall window rather than a per-bucket size.

rate(http_requests_total[$__interval])

Hardcoding a fixed bucket size like [5m] works fine for one specific zoom level and breaks the moment someone widens the time range to a week, either returning far too many data points to render sensibly or aggregating so coarsely the graph goes flat. Letting Grafana calculate it dynamically is what keeps one panel usable across every zoom level without manual tuning.

Proxy mode routes a panel's query through the Grafana server itself, the server holds the credentials and makes the request to the data source, and the browser never talks to the data source directly. Browser (direct) mode has the viewer's browser send the query straight to the data source, which means the data source has to be reachable from wherever the viewer is sitting and any auth has to work from the browser context.

Proxy mode is the right default almost every time. It keeps credentials on the server, works regardless of network topology between viewers and the data source, and is the only option most data source plugins even support anymore. Browser mode still shows up in some legacy setups and a few specific plugins, but it's the exception, not the rule.

A recording rule pre-computes an expensive PromQL expression on a schedule and saves the result as a new, cheap-to-query time series, instead of Grafana recalculating that same heavy aggregation from raw data every time someone loads the dashboard. If a dashboard's slowest panel is aggregating a high-cardinality query across every instance in a large fleet, moving that calculation into a recording rule means the panel now queries a small, pre-aggregated series instead of doing the expensive work at render time, every single time someone opens the page.

Each gets configured as its own named data source instance in Grafana, staging-prometheus and production-prometheus, say, each with its own URL and credentials. A dashboard then either hardcodes which instance it queries, or, more commonly for a dashboard meant to work across both, uses a data source variable so the viewer picks which instance to point every panel at from a dropdown, without maintaining two nearly identical dashboards.

No. PromQL is Prometheus's own query language, executed by Prometheus (or a Prometheus-compatible backend like Mimir or Thanos), not by Grafana. Grafana's Prometheus data source is a client: it sends the PromQL expression you write in the query editor to Prometheus's HTTP API, gets a JSON result back, and renders it. Grafana's query editor gives you autocomplete and metric browsing to help write PromQL, but the actual query execution and data retention live entirely on the Prometheus side.

LogQL is Loki's query language, and it's built around label selectors first, then a log line filter, rather than full-text search across every log ever ingested. A LogQL query always starts by narrowing down to a stream using labels, service, environment, log level, and only then filters the actual text of matching lines. That's a deliberate design choice: Loki doesn't index the full text of every log line the way Elasticsearch does, it indexes labels, which keeps ingestion cheap but means an unscoped, label-less query is either invalid or extremely slow.

{service="checkout-api", environment="production"} |= "timeout" | json | duration > 500ms

Split screen in Explore: run the Prometheus query for the metric on one side, select the exact time range where the spike occurred, then switch the other pane to the Loki data source scoped to the same service's labels and the same narrowed time range. Many teams also wire this up as a data link on the metric panel itself, an exemplar or a panel link that jumps straight from a specific data point into a pre-filtered Loki query for that instant, so on-call doesn't have to manually copy timestamps between two separate views during an incident.

Unified alerting is Grafana's current alert engine, built around the same alert rule model used by Prometheus's own Alertmanager, alert rules, notification policies, contact points, and silences, and it can evaluate alerts against any supported data source, not just Grafana's own dashboards. Legacy alerting was tied to individual dashboard panels, one alert per panel, with a simpler single-channel notification model. Unified alerting decouples the alert rule entirely from any specific dashboard panel, which is what lets one alert rule notify through multiple contact points based on routing logic instead of a single hardcoded channel (Grafana documentation, Alerting).

A silence suppresses notifications matching a label selector for a defined time window, without touching the underlying alert rule at all. The rule keeps evaluating and its state keeps updating, you just won't get paged for it during a planned maintenance window, say. Pausing an alert rule stops the rule from evaluating entirely, so its state stops updating and you lose visibility into whether the underlying condition is even still true. Silences are the right tool for "I know about this, stop paging me." Pausing is the right tool for "this rule itself is broken or needs editing and shouldn't run at all right now."

An evaluation group defines how often a set of alert rules is checked, its evaluation interval, and rules in the same group evaluate sequentially, one after another, on the same schedule. Grouping related rules together, all the alert rules for one service, say, means they all run on a consistent cadence and their evaluation timing is predictable relative to each other, which matters when one rule's expression references the result of another in the same group.

The pending period, sometimes called the "for" duration, is how long a rule's condition has to stay true continuously before the alert actually fires and notifies anyone. Without it, a metric that briefly crosses a threshold for one evaluation cycle and immediately drops back down would fire and resolve within seconds, generating noisy, low-value alerts. Setting for: 5m means the condition has to hold for five straight minutes before anyone gets paged, filtering out transient blips while still catching a genuinely sustained problem.

An organization is a top-level, largely isolated tenant inside a single Grafana instance, users, dashboards, data sources, and permissions in one org generally don't cross into another. A folder lives inside an org and groups dashboards together for both organizational and permission purposes, you can grant a specific team view or edit access to just one folder's dashboards without touching the rest of the org. Most single-team deployments never need more than one org and lean entirely on folders for structure.

The classic built-in roles are Viewer, Editor, and Admin, assigned at the org level, plus a separate Grafana Server Admin role for instance-wide administration across orgs. Role-based access control, an Enterprise feature, adds much finer-grained permissions on top, letting an org grant a specific user the ability to, say, manage data sources but not manage users, or edit alert rules but not delete dashboards, instead of forcing every non-trivial permission need into a full Admin grant.

Provisioning means defining a data source's configuration, its URL, auth method, and settings, in a YAML file that Grafana reads on startup, instead of an admin manually entering it through Settings in the browser. It matters for anything beyond a single throwaway instance: provisioned config is version-controlled, reviewable in a pull request, and reproducible across every environment automatically, so spinning up a new Grafana instance in staging doesn't mean someone has to remember and re-type every data source setting by hand.

apiVersion: 1
datasources:
 - name: Prometheus
  type: prometheus
  url: http://prometheus:9090
  access: proxy
  isDefault: true

Two common approaches: check dashboard JSON into a repo and provision it via a file-based dashboard provider so Grafana loads it from disk on startup, or manage dashboards through the Grafana Terraform provider, which lets dashboard definitions live alongside the rest of a team's infrastructure code and go through the same review and apply pipeline. Grafana 13 also added Git Sync directly into the product, letting a folder of dashboards sync bidirectionally with a Git repository, including signed commits, so a change made in the UI can flow back into version control without a separate export step.

Folders, with permissions scoped to each team, are the real fix, not a naming convention everyone's supposed to follow and nobody does. Put each team's dashboards in their own folder, restrict edit and even view access at the folder level where it's warranted, and searches and the dashboard browser naturally organize around that structure instead of relying on discipline. A shared, single flat folder with a hundred dashboards from five different teams is a support headache waiting to happen, and it's a fix that costs almost nothing to set up correctly from day one.

Grafana can install a plugin from a local zip or a direct URL using the grafana-cli plugins install command, or by placing the plugin's files directly into the configured plugins directory and restarting Grafana. The security consideration is that unsigned, unverified plugins run with the same access as Grafana itself, so a malicious or poorly vetted third-party plugin can be a real attack surface. That's exactly why Grafana enforces a plugin signature requirement by default and requires an explicit allowlist entry in the config to run an unsigned plugin at all.

rate() calculates the average per-second increase over the full time window given to it, smoothing out short spikes. irate() uses only the last two data points in the window, which reacts faster to sudden changes but is noisy and can produce misleading spikes on a graph with a wide time range.

rate(http_requests_total[5m])
irate(http_requests_total[5m])

For a dashboard panel that people will actually read over hours or days, rate() is almost always the right call because it produces a stable, trustworthy line. irate() has a real place in fast, ad-hoc Explore sessions when you're chasing a live spike second by second, but leaving it on a shared dashboard tends to generate false alarms from candidates and colleagues alike who mistake the noise for a real problem.

An exemplar is a sample trace ID attached to a specific metric data point, exposed by an instrumented application alongside its normal Prometheus metrics. Grafana renders exemplars as small markers directly on a metric graph, and clicking one jumps straight to the actual distributed trace for that exact request, in Tempo or another tracing backend, instead of leaving you to guess which of thousands of requests in that time bucket actually caused the latency spike. It's the practical bridge between a metrics dashboard and root-cause trace-level debugging, without needing to log every single request's trace ID separately.

First check whether multiple alert rules with overlapping conditions exist, a symptom of copy-pasted rules across dashboards that were never consolidated. Then check the notification policy tree for a rule matching at more than one level, if a policy and its child both match the same alert's labels and neither has continue: false set correctly, the alert can route to more than one branch and fire notifications through more than one contact point for the same event.

Also worth checking: whether the same underlying condition is being evaluated by both a Grafana-managed alert rule and a separately configured Alertmanager rule outside Grafana, which happens more often than people expect when a team migrates only part of their alerting into Grafana and leaves the rest on a standalone Alertmanager.

Grafana OnCall handles the parts unified alerting itself doesn't: on-call schedules and rotations, escalation chains that page a second person if the first doesn't acknowledge within a set window, and shift handoff tracking. Grafana's own alerting decides what fires and where it routes at the contact-point level. OnCall decides who's actually on the hook to receive that page right now, and what happens if they miss it.

API keys had a fixed expiration and were tied to an org rather than to an identity, so once created there was no clean way to see who created a given key, rotate just one key's permission without breaking others, or revoke access tied to a specific integration without hunting down which key belonged to it. Service accounts give a machine identity its own set of tokens, each with its own permission scope and expiration, that can be individually revoked and audited, which is the same shift most platforms eventually make once API keys start being shared between tools and nobody remembers which key does what.

A file-provisioned dashboard, by default, gets overwritten on Grafana restart or reprovisioning with whatever's currently in the source file, so any edit a user made directly in the UI without exporting and committing it back gets silently discarded the next time provisioning runs. Teams either lock provisioned dashboards to read-only in the UI to make that obvious upfront, or rely on the newer Git Sync workflow specifically so UI edits and file-based config stay reconciled instead of quietly clobbering each other.

Running Grafana in HA means multiple Grafana instances behind a load balancer, all pointed at the same shared database (for dashboards, users, and settings) instead of each instance's own local SQLite file. The tricky part isn't the stateless web tier, it's alerting: every Grafana instance in the cluster evaluates alert rules independently unless they're explicitly coordinated, so without proper HA configuration for alerting specifically, you can end up with duplicate alert evaluations and duplicate notifications firing from different instances for the exact same condition.

Vanilla Prometheus is single-node by design, its local storage and single-process query engine don't horizontally scale, and long-term retention past a few weeks usually means bolting on remote write to something else. Mimir is Grafana Labs's horizontally scalable, multi-tenant, long-term storage backend that speaks the Prometheus remote write and query API, so from Grafana's point of view it looks like a Prometheus data source, but underneath it can ingest from hundreds of Prometheus instances, scale storage and query load independently, and retain metrics for years instead of weeks.

High cardinality means a label has too many distinct possible values, a raw user ID or a full request path as a label value, for instance, instead of a bounded set like environment or region. Each distinct label combination creates a separate time series in the underlying store, so a high-cardinality label can explode the total series count into the millions. It shows up in Grafana as dashboards that time out or queries that return partial, truncated results, but the actual fix lives upstream in how metrics get instrumented and labeled at the application level, not in anything Grafana's query editor can work around after the fact.

It's a lightweight collector that runs alongside your applications and infrastructure, scraping metrics, tailing logs, and receiving traces, then forwarding all of it to the appropriate backend, Mimir, Loki, Tempo. Grafana Alloy is the newer, OpenTelemetry-native successor that consolidated several older Grafana Labs collector agents into a single configurable pipeline. It sits entirely outside Grafana the visualization layer itself, its job is getting data reliably into the stores Grafana later queries, not rendering anything.

Team size and change velocity are the real signal. A small team where one or two people own most dashboards can live fine with database-stored, UI-edited dashboards, it's faster to iterate and there's no review overhead for a low-risk change. Once more people are editing dashboards, especially across multiple teams sharing a Grafana instance, Git-backed provisioning earns its overhead: every change is reviewable, revertable, and attributable, and dashboards stop silently drifting because someone dragged a panel during an incident and never told anyone.

First isolate: open the panel's query inspector, which shows the raw request sent to the data source and how long the data source itself took to respond versus how long Grafana spent processing and rendering afterward. If the data source's own response time is the bulk of the total, the fix lives in Prometheus, Loki, or whatever's underneath, a too-wide time range, a high-cardinality label being aggregated over, missing recording rules for an expensive query.

If the data source responds fast but the panel still renders slowly, look at transformations stacked on the panel, a heavy join or a regex applied client-side across a large result set, and at how many series a single panel is rendering, a graph with thousands of individual lines from an unaggregated by (instance) clause is a classic self-inflicted performance problem that has nothing to do with Grafana's own health.