Browse the Knowledge Hub211 resources

Tools Library · Review and guide

Grafana review: pricing, alternatives and what it is

Grafana is an open-source dashboard and alerting application from Grafana Labs that queries data where it already lives, such as Prometheus, InfluxDB, Elasticsearch or SQL databases, and draws it on shared dashboards. For testers it is the usual way to watch a load test live beside server and application metrics. Grafana OSS is AGPL 3.0; Grafana Cloud and Grafana Enterprise are the paid offerings.

QAble has evaluated this tool and works alongside it. The factual sections are complete; our view is bounded to what we have actually seen rather than a long-term verdict.

last reviewed: 13 October 2026
version covered: Grafana 13
licence: Open source

Reviewed by Viral Patel

Co-Founder, QAbleLast reviewed 13 October 2026

ToolsGrafana

At a glance

Grafana at a glance

Official site

Vendor: Grafana Labs
Category: Monitoring
Licence: Open source (AGPL 3.0, with Grafana Cloud)
Platforms: Self-hosted, Cloud
Integrates with: Prometheus, InfluxDB, k6, JMeter, Elasticsearch
First released: 2014
Version reviewed: Grafana 13

Verdict

Our verdict on Grafana

Strengths

Queries Prometheus, InfluxDB, Elasticsearch, SQL databases and many more without copying data into Grafana first
Load test results and server metrics share one timeline, which turns a slow percentile into a diagnosis
Ready-made k6 and JMeter dashboards on grafana.com save building panels from scratch
Dashboards and data sources can be provisioned from files or synced with Git, so they live in version control
Grafana OSS is free; Grafana Cloud has a free tier with synthetic checks and k6 load testing included

Weaknesses

Stores nothing itself, so you must run and size a time-series database alongside it
Dashboards built by hand in the UI drift between environments unless they are provisioned or synced
Version 13 removed grafana-cli, grafana-server and Image Renderer plugin support, breaking older scripts
Synthetic monitoring and hosted k6 testing are Grafana Cloud features, not part of self-hosted OSS

Our take

Grafana fits QA work at the point where a performance test needs explaining rather than just measuring. Putting k6 or JMeter results and the system’s own CPU, memory, database and error metrics on one timeline shows whether latency climbed because of the code, the database or the load generator itself. QAble has evaluated Grafana for this purpose rather than maintained a long-running observability estate on it, so treat this as a bounded take. Two cautions. Grafana stores no metrics itself, so the quality of a test dashboard depends on the data source behind it and on tagging every run. And version 13 removed the grafana-cli and grafana-server commands and support for the Image Renderer plugin, so older setup guides and screenshot pipelines need checking before an upgrade.

We have evaluated this tool rather than maintained a long-running suite on it, so this is a bounded view rather than a long-term verdict. The rest of this page is factual.

How it works

What is Grafana and how does it work?

A query layer over other people’s data

Grafana does not collect or store metrics. Each panel sends a query to a data source plugin, such as PromQL to Prometheus, InfluxQL or Flux to InfluxDB, or SQL to Postgres, and renders the result. Grafana’s own database holds only dashboards, users, folders and alert rules. That design explains its reach, since any system with a plugin can appear on a dashboard, and its main limit for testers: retention, resolution and query speed are set by the data source, not by Grafana. A load test that writes one point per second for an hour is a data source sizing question long before it is a dashboard question.

Dashboards, variables and the shared time range

A dashboard is a JSON document of panels, each with queries and a visualisation, plus template variables that change what every panel queries. One time picker drives all panels, which is the property that matters for performance testing: request rate, p95 latency, error count, CPU and database connections line up on the same x-axis, so cause and effect are visible. A variable such as testid lets one dashboard show any run by filtering every query on a tag the load tool attached. Annotations add marked events, such as a deployment or the start of a soak test, across every panel.

Provisioning and Git Sync

Anything you click together in the UI lives in Grafana’s database, which is why dashboards quietly differ between staging and production. Provisioning fixes that: YAML files under the provisioning directory, /etc/grafana/provisioning in the Docker image, declare data sources and dashboard folders, and Grafana loads them at startup. Provisioned dashboards cannot be saved from the UI unless allowUiUpdates is set, and even then a later file change overwrites the edit. Grafana 13 also made Git Sync generally available, which connects dashboards and folders to a GitHub, GitLab, Bitbucket or plain Git repository and lets you save, commit and open a pull request from the UI.

Editions: OSS, Enterprise and Cloud

Grafana OSS is the AGPL 3.0 core. Grafana Enterprise is a commercial edition that adds features such as data source permissions, scheduled PDF reporting, auditing and premium data source plugins, including Splunk and Datadog, and it is enabled with a licence bought from Grafana Labs; the Docker docs now default to the grafana/grafana-enterprise image, which runs as OSS until licensed. Grafana Cloud is the hosted service, bundling Grafana with hosted metrics, logs and traces, plus testing products: Synthetic Monitoring and Grafana Cloud k6 for load tests. Those two testing products are Cloud features rather than part of the self-hosted download.

Strengths

What it does well

Live load test dashboards

k6 can stream metrics to Prometheus through remote write, and JMeter’s Backend Listener ships an InfluxDB client, so both tools feed Grafana while the test runs. Watching a run live means an obviously broken test is stopped after two minutes rather than discovered after an hour, and published dashboards such as 19665 for k6 with Prometheus give a working view on day one.

Correlating load with system behaviour

Because one dashboard can query several data sources, the load tool’s response times sit beside node CPU, garbage collection pauses, connection pool usage and error logs. That is the difference between reporting that p95 rose to two seconds at 300 users and showing that it rose when the database pool saturated, which is a finding developers can act on.

Annotations from pipelines

The HTTP API creates annotations with a time, an optional end time, tags and text. A CI job that annotates the start and end of each test run, the build number and the deployed version leaves a permanent record on every dashboard. Comparing two runs becomes a matter of reading the marked regions rather than reconstructing timestamps from logs.

Alerting on test and production signals

Grafana Alerting evaluates rules against data source queries and routes notifications to contact points such as email, Slack or PagerDuty. For QA this covers both soak tests, where an alert on rising memory or error rate catches a leak overnight, and production, where the same thresholds used in a performance test become the alerting baseline.

Synthetic checks in Grafana Cloud

Synthetic Monitoring runs black-box checks from public or private probes: HTTP, Ping, DNS, TCP and Traceroute, MultiHTTP for multi-step API flows, and Scripted and Browser checks written as k6 scripts. Teams that already write k6 tests can reuse the same language for production journey checks, and results land in the same Grafana as everything else.

Dashboards as reviewable code

Provisioned dashboard JSON and data source YAML can live beside the test suite, so a change to a performance dashboard goes through code review like any other test asset. With Git Sync in Grafana 13, people who prefer the UI can still edit visually and open a pull request, which removes the usual tension between clicking and versioning.

Pricing

Grafana pricing and licensing

Grafana OSS is free under the AGPL 3.0 licence and you pay only for the servers and storage you run it on. Grafana Cloud has three tiers: Free, Pro and Enterprise. On the Grafana Cloud pricing page today, Pro is listed at $19 a month as a platform fee plus usage for each product above its allowance, and Enterprise starts at a committed annual spend. Self-managed Grafana Enterprise is priced through Grafana Labs sales. For most test teams the real cost is the data source behind Grafana, not Grafana itself.

Licence: Grafana OSS is AGPL 3.0, after Grafana Labs moved its core projects from Apache 2.0 in 2021. Running it internally, unmodified, is the common case; review the AGPL terms if you modify and offer it as a service.
Grafana Cloud Free: no card required, with 10,000 active metric series, 50 GB each of logs, traces and profiles at 14-day retention, 100,000 API and 10,000 browser synthetic executions, and 500 k6 virtual user hours a month (list allowances on the pricing page today).
Grafana Cloud Pro: a platform fee plus pay-as-you-go usage per product, such as active series, GB ingested, synthetic executions and k6 virtual user hours, so a large load test month costs more than a quiet one.
Grafana Enterprise: a commercial licence for self-managed installs, adding data source permissions, reporting, auditing and premium data source plugins. Priced by quote.
Hidden cost: the time-series database. Prometheus or InfluxDB need disk, memory and retention planning, and high-cardinality tags from load tests, such as full URLs, can multiply series counts quickly.

Checked against the vendor’s own pages on 13 October 2026. Pricing changes; confirm on the official site before buying.

Getting started

Getting started with Grafana

Setup, step by step

Install Docker, then start Grafana OSS with the command below and open http://localhost:3000.
Sign in as admin with password admin, and set a new password when prompted.
For a load test stack, save the Compose file and data source YAML below, then run docker compose up -d.
Import dashboard 19665 (k6 Prometheus) from grafana.com through Dashboards, New, Import.
Run a k6 test with the Prometheus remote write output and a testid tag, and watch the dashboard fill.

Install

docker run -d -p 3000:3000 --name=grafana grafana/grafana
# grafana/grafana is OSS; the docs default to grafana/grafana-enterprise

# k6 results into Prometheus, tagged per run
K6_PROMETHEUS_RW_SERVER_URL=http://localhost:9090/api/v1/write \
K6_PROMETHEUS_RW_TREND_STATS="p(95),p(99),min,max" \
k6 run -o experimental-prometheus-rw --tag testid=run-001 script.js

A first example

# docker-compose.yaml: Prometheus to receive k6 metrics, Grafana to show them
services:
  prometheus:
    image: prom/prometheus
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      # k6 pushes metrics, so Prometheus must accept remote writes
      - --web.enable-remote-write-receiver
    ports:
      - '9090:9090'
  grafana:
    image: grafana/grafana
    ports:
      - '3000:3000'
    volumes:
      # Everything under provisioning/ is loaded at startup
      - ./provisioning:/etc/grafana/provisioning
      - grafana-storage:/var/lib/grafana
volumes:
  grafana-storage: {}

# provisioning/datasources/prometheus.yaml
# apiVersion: 1
# datasources:
#   - name: Prometheus
#     type: prometheus
#     access: proxy
#     url: http://prometheus:9090   # service name, not localhost
#     isDefault: true

What trips people up first

Pointing the data source at localhost. Inside the Grafana container, localhost is the container itself, so a Prometheus or InfluxDB URL of http://localhost:9090 fails with a connection error even though the same address works in your browser. Use the Compose service name, such as http://prometheus:9090, or host.docker.internal when the database runs on your machine rather than in Compose. The second common surprise is an empty k6 dashboard: Prometheus refuses k6’s pushes unless it was started with --web.enable-remote-write-receiver, and the dashboard’s time range must cover the run.

In practice

Using Grafana in practice

Laying out a performance test dashboard

Build the dashboard around the questions a test run must answer, in reading order. The top row shows load and outcome from the load tool: virtual users, request rate, error rate and p95 and p99 latency. The next rows show the system under test: CPU and memory per service, database connections and slow queries, queue depth, and application error logs. Add a testid variable populated from the tag the load tool writes, so the same dashboard filters to any run, and a second instance of the variable if you want to compare two runs side by side. Keep the load generator’s own CPU on the dashboard too: a saturated generator produces latency that looks like a server problem and is not.

Provisioning dashboards from the repository

Store dashboard JSON and data source YAML in the same repository as the performance tests, under a provisioning folder, and mount it into Grafana. The dashboard provider below loads every JSON file from a directory and builds folders from the directory structure. Export a dashboard you designed in the UI through its share or export option, commit the JSON, and from then on change it through pull requests. With allowUiUpdates left false, nobody can save an edit that the next deployment would overwrite, which is the behaviour you want for a shared test dashboard.

# provisioning/dashboards/perf.yaml
apiVersion: 1
providers:
  - name: performance-tests
    type: file
    # Reject UI saves: the files in Git are the source of truth
    allowUiUpdates: false
    options:
      path: /etc/grafana/provisioning/dashboards/json
      # performance/checkout.json becomes folder "performance"
      foldersFromFilesStructure: true

Annotating test runs from GitHub Actions

Create a service account in Grafana with permission to create annotations, store its token as a repository secret, and post an annotation when the load test starts and finishes. Omitting dashboardUID makes the annotation organisation-wide, so it can appear on any dashboard that queries the built-in Grafana annotations source filtered by tag. In Grafana 13 the /api routes are deprecated in favour of /apis but still work; the annotations endpoint below is the documented one today, and it is worth checking the release notes before relying on it long term.

# .github/workflows/load-test.yml
name: load-test
on: workflow_dispatch
jobs:
  k6:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: grafana/setup-k6-action@v1
      - name: Mark the start of the run in Grafana
        run: |
          curl -sf -X POST "${{ vars.GRAFANA_URL }}/api/annotations" \
            -H "Authorization: Bearer ${{ secrets.GRAFANA_TOKEN }}" \
            -H "Content-Type: application/json" \
            -d '{"tags":["loadtest","run-${{ github.run_id }}"],"text":"k6 run ${{ github.run_id }} started"}'
      - name: Run k6 and stream metrics to Prometheus
        env:
          K6_PROMETHEUS_RW_SERVER_URL: ${{ vars.PROM_RW_URL }}
        run: k6 run -o experimental-prometheus-rw --tag testid=run-${{ github.run_id }} tests/checkout.js

Feeding JMeter results into Grafana

JMeter’s Backend Listener has shipped an InfluxDB client since JMeter 3.2, sending metrics over HTTP or UDP while the test runs. Add a Backend Listener to the test plan, select InfluxDBBackendListenerClient, and point influxdbUrl at your database. For InfluxDB 1.x create a jmeter database; for InfluxDB 2.x create a jmeter bucket, set influxdbToken, and add bucket and org as query parameters on the URL. Then add InfluxDB as a Grafana data source with the matching query language. Two parameters matter most. summaryOnly defaults to true, which sends totals only, so set it to false to see each sampler. testTitle is written as start and end events that Grafana can show as annotations, so give every run a distinct title. Run load tests from the command line rather than the JMeter GUI.

Keeping dashboards fast and trustworthy

Most slow or misleading test dashboards come from tags. Tagging every request with a full URL that contains IDs creates a new series per user or order, which inflates Prometheus memory and Grafana Cloud bills, so group requests under a name tag instead. Prefer percentiles computed by the load tool or native histograms over averages, which hide the tail that users feel. Set dashboard refresh to match the data source scrape or push interval rather than five seconds. Finally, record the dashboard link and time range in the test report, because the dashboard is evidence only for as long as the data source retains the data.

Pitfalls

Common pitfalls

Following setup guides that call grafana-cli or grafana-server

Why it happens: Grafana 13 removed both commands. Scripts, Dockerfiles and tutorials written for earlier versions fail with a missing command error after an upgrade.

The fix: Use grafana cli and grafana server, the subcommand forms, and in Docker prefer the GF_PLUGINS_PREINSTALL environment variable to install plugins at startup.

Screenshot or PDF pipelines breaking after upgrading to 13

Why it happens: Grafana 13 removed support for the Image Renderer plugin, so panel screenshots and scheduled reports that depended on it stop working.

The fix: Read the Grafana 13 breaking changes and current rendering documentation before upgrading, and test any report or alert image workflow on a staging instance first.

Upgrading from 12.x with Git Sync enabled straight to 13.0.0

Why it happens: The Grafana 13 release notes describe a migration bug in 13.0.0 that could lose or revert dashboards and folders for 12.x instances with Git Sync on, and moving to 13.0.1 afterwards does not recover them.

The fix: Back up the Grafana database before any major upgrade and go directly to the latest 13.x patch. If 13.0.0 already ran, restore the backup first.

Comparing runs that cannot be told apart

Why it happens: Without a run identifier, every k6 or JMeter run writes to the same series, so a dashboard shows overlapping lines and a regression cannot be attributed to a build.

The fix: Tag every run, for example with --tag testid in k6 or a distinct test title in JMeter, add a dashboard variable on that tag, and annotate the run with the build number.

Editing a provisioned dashboard and losing the change

Why it happens: Provisioned dashboards are reloaded from files. If allowUiUpdates is true, a UI edit is saved to the database but replaced the next time the file changes.

The fix: Treat the file as the source of truth: export the edited JSON, commit it, and let provisioning or Git Sync deploy it.

High-cardinality tags overwhelming the data source

Why it happens: Load tools tag requests with URLs, and dynamic paths such as /orders/12345 create a new series per value. Prometheus memory and Grafana Cloud active-series charges both scale with series count.

The fix: Name requests in the load script so they share a tag, drop unneeded tags before they are written, and check series counts after the first test run.

Compared

Grafana alternatives compared

Tool	Licence	Hosting	Stores metrics itself	Synthetic checks	Cost model
Grafana	AGPL 3.0; Cloud and Enterprise paid	Self-hosted or Grafana Cloud	No, queries external data sources	Grafana Cloud only, including k6 browser	OSS free; Cloud fee plus usage
Prometheus	Apache 2.0	Self-hosted	Yes, local time-series database	Via blackbox exporter probes	Free; you run the servers
Datadog	Commercial	SaaS, Agent on your hosts	Yes, in Datadog’s cloud	API, browser and mobile app tests	Per host, GB and test run
New Relic	Commercial, with a free tier	SaaS	Yes, in New Relic’s cloud	Yes, 500 checks a month free	Per GB ingested plus per user

FAQ

Frequently asked questions

What is Grafana?

What are the best Grafana alternatives?

The alternatives most often weighed against Grafana are Prometheus, Datadog and New Relic. The comparison on this page sets them side by side on licence, hosting, stores metrics itself, synthetic checks and cost model, and the verdict above says where Grafana is the wrong choice and which of them to pick instead.

Is Grafana free?

Grafana OSS is free and open source under the AGPL 3.0 licence, with no limit on users or dashboards. Grafana Cloud also has a free tier, which on the pricing page today includes 10,000 active metric series, 50 GB of logs and traces, synthetic monitoring executions and 500 k6 virtual user hours a month. Grafana Cloud Pro, Grafana Cloud Enterprise and self-managed Grafana Enterprise are paid.

How do I see k6 results in Grafana?

Send k6 metrics to a time-series database that Grafana can query. The documented route is Prometheus remote write: start Prometheus with --web.enable-remote-write-receiver, run k6 with -o experimental-prometheus-rw and K6_PROMETHEUS_RW_SERVER_URL set to its write endpoint, then import dashboard 19665 from grafana.com. Add --tag testid to each run so dashboards can filter one run. Grafana Cloud k6 is the hosted alternative.

Can Grafana show JMeter results?

Yes. JMeter’s Backend Listener includes an InfluxDB client that sends results while the test runs. Configure it with your InfluxDB URL, plus a token, bucket and organisation for InfluxDB 2.x, add InfluxDB as a Grafana data source, and build or import a JMeter dashboard. JMeter also ships a Graphite client if Graphite is what your team already runs.

Grafana vs Prometheus: which do I need?

Usually both, because they do different jobs. Prometheus collects and stores metrics and evaluates PromQL queries and alert rules. Grafana stores no metrics and draws dashboards over Prometheus and other sources. Prometheus’s own web interface is fine for ad hoc queries, but Grafana is where shared test dashboards, annotations and cross-source views live.

Grafana vs Datadog for performance testing?

Grafana suits teams that already run Prometheus, InfluxDB or similar and want free, self-hosted dashboards, with Grafana Cloud as a hosted option. Datadog is a single commercial platform that collects metrics, traces and logs through its own Agent, with APM that breaks a slow request down by service and query. Grafana costs less in licences and more in operating the data sources.

What changed in Grafana 13?

Grafana 13 was announced at GrafanaCON in April 2026. Git Sync for dashboards became generally available and dynamic dashboards are on by default, migrating existing dashboards when opened. The grafana-cli and grafana-server commands were removed, as was support for the Image Renderer plugin, and the /api routes are deprecated in favour of /apis. Read the breaking changes list before upgrading a shared instance.

Does self-hosted Grafana include synthetic monitoring?

No. Synthetic Monitoring, with HTTP, DNS, TCP, MultiHTTP and k6 scripted and browser checks from public or private probes, is a Grafana Cloud feature. Self-hosted teams usually pair Grafana with the Prometheus blackbox exporter for simple endpoint probes, or run k6 on a schedule and push results to their own data source.

Alternatives