dotdc/grafana-dashboards-kubernetes: a dashboard set built for kube-prometheus-stack

What dotdc/grafana-dashboards-kubernetes actually ships

The repository is a collection of Grafana dashboard JSON files under a dashboards/ directory, plus the packaging needed to deliver them: a kustomization.yaml, an argocd-app.yml, a .releaserc.json for semantic-release, and a .pre-commit-config.yaml. There is no Go binary, no controller, no sidecar of its own. The README describes the set as "modern" Grafana dashboards for Kubernetes, inspired by dashboards from kubernetes-mixin and grafana.com.

The audience is narrow and specific. The README states the dashboards are made and tested for the kube-prometheus-stack chart, and that they should work well with others as soon as kube-state-metrics and prometheus-node-exporter are installed on the cluster. If you run a different monitoring stack that still exposes those two exporters to Prometheus, the queries have something to read. If you do not run those exporters, the panels are empty.

Eight dashboards are listed: k8s-addons-prometheus.json, k8s-addons-trivy-operator.json, k8s-system-api-server.json, k8s-system-coredns.json, k8s-views-global.json, k8s-views-namespaces.json, k8s-views-nodes.json and k8s-views-pods.json. The split is deliberate: four cover a single component or add-on, four cover a level of the cluster hierarchy. That structure is the main design decision in the project, and it is why the set is useful as a whole rather than as isolated panels.

Why a level-based dashboard split beats one giant cluster board

Most Kubernetes dashboards fail the same way: one page with every metric, sorted by nothing, so an operator scrolls past node pressure to find a crashing pod. This project separates the hierarchy instead. The global view answers whether the cluster is healthy. The namespaces view narrows to a tenant or team. The nodes view covers capacity and pressure per machine. The pods view covers restarts, CPU and memory per workload.

That progression matches how an incident is actually worked. You start broad, then descend. The trade-off is that you cannot see a pod and its node in the same panel, so a diagnosis that needs both requires two dashboards open side by side. The README does not describe any cross-dashboard linking, so that navigation is manual.

A second design choice is the Prometheus Datasource variable. The README states the dashboards include it so they will work on a federated Grafana instance. In practice that means the datasource is a template variable rather than a hardcoded UID, which is what makes the JSON files portable between environments. It also means the first thing to check when panels render empty is that this variable resolves to a datasource that can actually query the cluster's Prometheus.

Installing dotdc/grafana-dashboards-kubernetes and importing the first dashboard

The README says that in most cases you clone the repository or your fork first. That gives you the JSON files locally, which is what the manual import path needs.

git clone https://github.com/dotdc/grafana-dashboards-kubernetes.git
cd grafana-dashboards-kubernetes

For the manual route, the README describes the UI steps: hover the + sign in the left menu, click Import, then use the Upload JSON file button to load the files one by one from your local copy. The dashboard should appear in the folder you chose during import, with panels populated from your Prometheus datasource.

The alternative is grafana.com. The same Import page accepts a dashboard ID under Import via grafana.com, then you click Load. The README provides an ID table for this, and the related searches show people arriving at this repository looking for Grafana dashboard 15757, so the grafana.com listing is a real entry point. Repeat the load step for each dashboard you want.

If you deploy through ArgoCD, ConfigMaps or Terraform, the README says you also need the dashboards sidecar enabled and configured on the Grafana Helm chart. The example is given as kube-prometheus-stack values:

# kube-prometheus-stack values
grafana:
  sidecar:
    dashboards:
      enabled: true
      defaultFolderName: "General"
      label: grafana_dashboard
      labelValue: "1"
      folderAnnotation: grafana_folder
      searchNamespace: ALL
      provider:
        foldersFromFilesStructure: true

With that in place, the sidecar watches for ConfigMaps carrying the grafana_dashboard label and loads them into Grafana. The provider setting foldersFromFilesStructure is what turns the directory layout into Grafana folders.

The known issues are about labels, not about panels

The README has a Known issue(s) section, and it is the most useful part of the document. Three of the four entries concern the same dashboard, k8s-views-nodes, and two of them are about identity rather than queries.

One issue is described as broken panels when a node changes its IP address. Another is broken panels on k8s-views-nodes due to the nodename label. Both point at the same weakness: the node view depends on labels that are not guaranteed to be stable over the life of a cluster. Nodes get re-addressed, and the nodename label is not universally present or consistent across exporters and providers. The README documents these as known issues rather than offering a fix, so a reader should treat them as conditions to check before relying on that dashboard during an incident.

The third entry is a resolution problem: broken panels due to a too-high resolution. That is a query cost and rendering issue, and the README does not give a threshold. The fourth is Windows support, listed as a known issue, which tells you the node-level metrics assume a Linux node. If your cluster is mixed, the node view is not a complete picture.

None of this is disqualifying. It does mean the node dashboard deserves a test on your own cluster before it becomes the page you open at 3am.

Version requirements rule out older Grafana instances

The README is explicit that the dashboards are not backward compatible with older Grafana versions, because they use newer features. Three are named with the versions that introduced them: gradient mode in Grafana 8.1, the time series visualization panel in Grafana 7.4, and the $__rate_interval variable in Grafana 7.2.

That is a hard floor, and it is the first thing to verify. A Grafana 7.3 instance will not render the time series panels correctly, and anything below 8.1 loses gradient mode. Because the JSON is imported rather than installed as a plugin, there is no version negotiation: you get broken or empty panels, not an error message.

The $__rate_interval detail is the one with real operational consequences. It exists so that rate queries pick a window appropriate to the dashboard's resolution and scrape interval, which is why the README mentions a too-high resolution as a separate known issue. If you shorten the dashboard time range aggressively, the interval shrinks and the queries get more expensive against Prometheus. The two notes belong together: the variable is what makes the queries portable, and resolution is what makes them costly.

How this differs from kubernetes-mixin and hand-built boards

The README names kubernetes-mixin as an inspiration, and the difference in approach is worth stating plainly. kubernetes-mixin is a source project: you take Jsonnet, compile it with a build toolchain, and generate both recording rules and dashboards. The output is tied to the rules it generates, and changing a panel means changing Jsonnet and recompiling.

This repository is the opposite. It ships finished JSON files, plus packaging options for ArgoCD, ConfigMaps, Terraform and the Grafana Operator. There is no compilation step and no recording rules. You import the file, or you let a sidecar load it. That makes adoption fast and customization shallow: editing a panel means editing JSON, and there is no upstream merge path for your change other than a pull request against the repository.

If you already run a Jsonnet pipeline and generate dashboards from mixin libraries, adding this set means maintaining two sources of truth for the same cluster. If you have no pipeline, the JSON files are the shorter path. The project also has a Trivy Operator dashboard, which the mixin libraries do not cover, so the add-on dashboards are a reason to look here even if you generate the core views elsewhere.

Maintenance, releases and what the Apache-2.0 licence means here

Releases follow semantic versioning, and the README states that conventional commits drive automated releases through semantic-release. The recent tags are v3.0.8 and v3.0.7, both pushed on 2026-09-20, with v3.0.6 before them on 2026-03-24. The last push to the repository was on 2026-09-20. Two patch releases on the same day suggests a fix landed and was followed by a correction, which is normal for this release model but worth knowing if you pin a version: pin v3.0.8 rather than v3.0.7.

Upgrade cost is low in the sense that a dashboard is a file, and replacing it is a copy. It is not zero. Because there is no migration tooling, a version bump can change panel queries or template variables, and any local edits you made to the JSON are lost when you overwrite the file. Teams that customize panels should keep their changes in a fork, which the README anticipates when it says you may need to clone the repository or your fork.

The licence is Apache-2.0, which permits commercial use and modification and requires that the licence and notices be preserved. That is a permissive arrangement, and it is the same licence family as much of the Kubernetes ecosystem. It is not legal advice, and if you redistribute the dashboards inside a product, the notice requirements are the part to read.

Editorial conclusion

Adopt these dashboards if you already run kube-prometheus-stack or any stack with kube-state-metrics and prometheus-node-exporter, and you want Kubernetes views at global, namespace, node and pod level without writing JSON panels yourself. Skip them if your Grafana predates 8.1, if you monitor Windows nodes, or if you need a dashboard that survives node IP or nodename label changes without intervention. Before importing anything, check the Grafana version in your instance, confirm kube-state-metrics and prometheus-node-exporter are scraped, and read the Known issue(s) section of the README for the exact conditions under which k8s-views-nodes panels break.

Frequently asked questions

Official sources

1. dotdc/grafana-dashboards-kubernetes on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases