Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
To add a Prometheus dashboard to Grafana, first add a reachable Prometheus data source, then import a dashboard from JSON or a Grafana dashboard ID/URL and map its Prometheus reference to that data source. You can also create panels manually with PromQL. If panels are empty, check the network path, data-source mapping, query, time range, labels, and whether the required metrics actually exist.
How Grafana, Prometheus, and a dashboard fit together
Prometheus stores time-series metrics and evaluates PromQL queries. Grafana is the visualization layer: a dashboard contains panels, and each panel sends a query to a configured data source. Importing a dashboard does not install Prometheus, create missing metrics, or automatically discover the correct server. The destination Grafana must already be able to reach the Prometheus HTTP endpoint.
A typical host-monitoring setup uses Prometheus together with Node Exporter. Prometheus scrapes Node Exporter, stores the resulting series, and Grafana queries those series. The same sequence applies to application exporters and other Prometheus-compatible producers: the dashboard can only display metrics that the Prometheus server is collecting.
What you need before adding a dashboard
- A running Prometheus server. Know its HTTP address and port. A common local address is
http://localhost:9090, but that value is valid only when the Grafana process can resolve and reach that same machine. - Metrics that match the dashboard. A dashboard built for Node Exporter will expect Node Exporter metric names and labels. A dashboard built for a different exporter may import successfully but remain empty.
- Access to configure Grafana. UI data-source changes require an organization-administrator account. If you cannot receive that permission, an administrator can provision the source with YAML or Terraform.
- A dashboard definition. You may have a JSON file, a Grafana dashboard URL or numeric ID, or JSON text copied from another system. You can also start with an empty dashboard and write the panels yourself.
Before touching the dashboard, verify the Prometheus side. Confirm that the Prometheus process responds and that at least one metric expected by the dashboard exists. Grafana’s getting-started workflow follows this order: install and configure Prometheus and Node Exporter, check the collected metrics in Grafana Explore, and then build or import visualizations. Doing the checks first separates a metrics problem from a Grafana configuration problem.
#1 Best Overall
Step 1: Verify Prometheus is collecting the required series
Check the endpoint from the Grafana network location
Open the Prometheus web interface or otherwise test its HTTP endpoint from the environment where Grafana runs. A successful response proves that the service is listening, but it does not prove that the required exporter is being scraped. Check the target status and query a known series before importing anything.
For a same-host installation, the URL may be http://localhost:9090. In a container deployment, that value usually points back to the Grafana container itself. Use the Prometheus container name, a service name on the shared network, or another address that is routable from Grafana instead.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteConfirm the metric names and labels
Look for the metric family used by the dashboard and inspect its labels. PromQL is label-sensitive: a query can return no series when a dashboard assumes a label, job name, instance format, or exporter prefix that your setup does not use. Record the actual names and labels; they are useful when you later inspect an empty panel.
Check the time window
Use a time range that includes recent samples. A newly installed exporter may have no historical data, and a dashboard opened with an older custom range can appear blank even though current scraping works. This check belongs on the Prometheus side as well as in Grafana.
Step 2: Add Prometheus as a Grafana data source
Prometheus support is built into Grafana, so a separate Grafana plugin installation is not required. The navigation wording varies by Grafana version, but the current paths are Connections > Add new connection or Connections > Data sources.
Rank #2
- Sign in to Grafana with an organization-administrator account.
- Open Connections, then choose Add new connection. If your version presents a data-source list first, open Data sources and select Add data source.
- Search for and select Prometheus.
- Enter the Prometheus server URL in the URL field. Use
http://localhost:9090only for a same-host arrangement. For separate containers, enter the reachable Prometheus service hostname and port. - Save the configuration and run Grafana’s connection test.
The URL must be reachable from the Grafana server, not merely from your browser. A browser may be able to open a private address that the Grafana backend cannot route to, or the reverse may be true. A failed test therefore points first to the URL, DNS, firewall, container network, TLS settings, or a stopped Prometheus process.
“Grafana provides built-in support for a Prometheus data source.” — Grafana Labs documentation.
When UI configuration is unavailable
Data-source configuration can also be managed through provisioning YAML or Terraform. This is useful for repeatable environments and for teams that do not grant dashboard editors organization-administrator rights. Have an administrator apply the provisioning configuration, then use the resulting data-source name when importing dashboards.
Step 3: Import an existing Prometheus dashboard
Once the data source passes its connection test, open Dashboards > New > Import dashboard. Grafana accepts three input forms:
| Import method | What you provide | When it is useful |
|---|---|---|
| Upload JSON | A dashboard JSON file saved locally | Moving a dashboard between Grafana instances or keeping it under version control |
| Grafana dashboard URL or ID | A URL from the Grafana dashboard library or its numeric ID | Starting from an available dashboard definition without downloading it first |
| Paste JSON | Dashboard JSON text in the import field | Quick transfers and dashboards copied from another administration interface |
- Choose the input type and provide the JSON, URL, or ID.
- Review the dashboard name and destination folder.
- Review the UID and any metric-prefix or variable options exposed by the importer. Keep the UID only when it will not collide with an existing dashboard in the destination.
- When Grafana displays data-source mappings, map every imported Prometheus reference to the Prometheus data source you configured in Step 2.
- Click Import, open the resulting dashboard, and test several panels across a recent time range.
Mapping is a required part of the process, not an optional cleanup step. A dashboard JSON can refer to a data source by a name, UID, or another internal reference that does not exist in your Grafana organization. Grafana lets you replace that reference with a source that does exist locally.
“During import, Grafana lets you map those references to data sources that exist in your environment so the dashboard can display data correctly.” — Grafana Labs documentation.
Review a dashboard before relying on it
Grafana’s dashboard library includes official and community dashboards for common technologies. Treat a community dashboard as configuration to inspect rather than as a guarantee that it matches your installation. Open representative panels and check:
- the PromQL expression and the metric names it uses;
- template variables, including the labels or data-source settings they depend on;
- the exporter or application that must produce the metrics;
- the expected job and instance label values;
- any recording rules, plugins, or version-specific features referenced by the JSON.
Importing a dashboard does not install a required exporter or create recording rules. If those prerequisites are absent, the layout may look correct while every query returns an empty result.
Step 4: Validate the imported dashboard
Test a simple panel first
Open one panel, inspect its query, and run it over a short recent range. A simple series query is easier to validate than a complex rate, aggregation, or variable-driven expression. If the simple query returns data, move on to panels that depend on more specific labels or recording rules.
Recommended Free Tools
Check variables before individual panels
Dashboard variables commonly filter by job, instance, device, or application. If a variable has no options, downstream panels may receive an empty label value and show no data. Inspect the variable query and compare its assumed labels with the labels actually present in Prometheus.
Save only after the mapping is correct
After confirming the data source and queries, save the dashboard. Saving preserves the panel definitions, visualizations, variables, folder placement, and the selected data-source references for subsequent viewers.
Build a Prometheus dashboard manually
An import is convenient, but a small custom dashboard is often clearer when no existing definition matches your metrics. Each panel needs a query and a visualization; Prometheus panels use PromQL because the data source determines the query language.
- Open Dashboards > New > New Dashboard.
- Choose Add visualization or add a new panel.
- Select the Prometheus data source.
- Enter or construct a PromQL query using a metric that you verified in Prometheus.
- Run the query and inspect the returned series and labels.
- Select an appropriate visualization. Grafana’s learning workflow starts with a time-series graph, but the visualization list also offers other panel types.
- Set the panel title, units, legend, thresholds, and time options that make the result understandable.
- Save the panel and then save the dashboard, choosing its name and folder.
Start with one meaningful question per panel: for example, whether a host metric changes over time or how a series differs by instance. Add label filters only after the unfiltered query returns the expected series. This approach makes a typo or label mismatch visible before it is hidden inside a larger expression.
Free tools Windows power users keep installed
One-click scans. No signup required.
Add deployment and alert context with annotations
Annotations place event markers over time-series panels. They can show deployments, threshold events, or other operational changes alongside metric data.
- Edit the dashboard and open its annotation settings.
- Add an Annotation query.
- Select the Prometheus data source.
- Enter a PromQL expression that returns the event series.
- Set the minimum step and map the fields that contain event time, text, or tags.
- Test the annotation query if your Grafana version provides that action, then save the dashboard.
Prometheus annotations require a configured and readable Prometheus data source plus metrics that represent the events. An annotation definition cannot create event data that Prometheus never collected.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Grafana Cloud or self-managed Grafana?
Both deployment models support importing dashboards from JSON, URLs, and IDs. The practical difference is who operates Grafana and how it reaches Prometheus.
| Consideration | Self-managed Grafana | Grafana Cloud |
|---|---|---|
| Operations | Your team runs Grafana, upgrades it, backs it up, and maintains its availability. | The hosted service reduces platform maintenance; you still manage dashboards, queries, permissions, and metric sources. |
| Network path | Grafana can often reach a private Prometheus directly on the local network. | Prometheus must be reachable through an appropriate hosted connectivity path, such as a reachable endpoint or Private Data Source Connect configuration. |
| Dashboard portability | Imports accept JSON, URLs, and IDs, subject to data-source mappings and version compatibility. | The same import forms are available, with the same need to map data sources and verify compatibility. |
| Control and governance | Local infrastructure gives you direct control over storage, network boundaries, and upgrade timing. | The hosted model reduces infrastructure work while placing more of the platform operation with the service provider. |
Choose based on the operational boundary rather than on dashboard syntax. A dashboard JSON does not remove the need to solve the network path to Prometheus, and moving the JSON between hosted and self-managed Grafana does not automatically translate data-source references.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Troubleshoot an empty or failing dashboard
| Symptom | Likely cause | What to check |
|---|---|---|
| Connection refused or data-source test fails | Prometheus is stopped, the URL is wrong, or Grafana cannot route to it. | Confirm the Prometheus process, test the endpoint from the Grafana environment, and correct DNS, port, firewall, TLS, or container-network settings. |
| Grafana and Prometheus run in separate containers | localhost:9090 points to the Grafana container rather than the Prometheus container. |
Use the Prometheus service or container hostname on the shared network, or another address reachable from Grafana. |
| Import succeeds but every panel is empty | The imported Prometheus reference was not mapped to the configured source. | Reopen the import or dashboard settings and ensure every Prometheus reference points to the working data source. |
| Only some panels are empty | Those panels use different metrics, labels, recording rules, or exporter assumptions. | Inspect each panel’s PromQL, compare its metric and label requirements with Prometheus, and check the dashboard’s variables. |
| Data exists but is outside the visible chart | The selected time range or panel time override excludes the samples. | Switch to a recent range and remove or adjust a panel-specific time override. |
| Variable dropdowns are blank | The variable query expects a label or series that is not present. | Run the variable query in Explore and compare its assumed job, instance, or other label with actual series. |
| You cannot add the data source | Your account lacks organization-administrator permission. | Ask an administrator to configure it, or use YAML provisioning or Terraform under your organization’s change process. |
Use Explore to isolate the fault
Grafana Explore is useful for testing a metric independently of dashboard layout. Select the Prometheus source, run the panel’s query, and progressively simplify it: remove a label filter, try a known metric, and broaden the time range. If the simplified query still returns nothing, investigate Prometheus collection. If it works in Explore but not in the panel, inspect the panel’s variables, transformations, overrides, and time settings.
Check exporter and naming assumptions
An imported dashboard may target a different exporter or metric naming convention. For example, a host dashboard can assume Node Exporter while your Prometheus server scrapes only application metrics. Install and configure the required exporter in accordance with your environment, or edit the dashboard queries to use metrics you actually collect. Do not rename a metric in a panel without checking every related variable and panel query.
Operational practices that prevent repeat failures
- Keep the data-source name deliberate. Consistent names make imports and provisioning mappings easier to understand across environments.
- Version-control dashboard JSON. Store exported definitions with the PromQL and variable changes that explain why a panel was modified.
- Test after exporter changes. A dashboard can remain saved while an exporter upgrade changes labels or removes a series.
- Separate import validation from production rollout. Review queries, variables, required exporters, and permissions before placing a community dashboard in a shared production folder.
- Limit access to configuration. Give organization-administrator rights only to accounts that need them; use provisioning for repeatable, audited changes.
- Document the network path. Record whether Grafana reaches Prometheus through localhost, a service hostname, a private address, or a hosted connectivity feature.
The reliable sequence
The shortest dependable path is: verify Prometheus and its metrics, add and test the Prometheus data source from Grafana’s network location, import the dashboard, map every data-source reference, and then validate representative PromQL queries. Build panels manually when an import does not match your metrics, and add annotations only after event series and read access are available. When a panel is empty, debug the path in that same order—connectivity, mapping, query and labels, time range, then metric availability—rather than repeatedly re-importing the dashboard.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
