Grafana dashboards aren’t really "saved" in the way you might think; they’re more like snapshots of a particular state, and the history is a log of those states.
Let’s see this in action. Imagine you have a dashboard named "My Critical Metrics." You’ve been tweaking it, and now it’s broken.
{
"dashboard": {
"id": 123,
"title": "My Critical Metrics",
"panels": [
{
"type": "graph",
"title": "CPU Usage",
"targets": [
{
"expr": "100 - avg by (instance) (irate(node_cpu_seconds_total{mode='idle'}[5m]))",
"legendFormat": "{{instance}}"
}
]
}
],
"version": 5
},
"message": "Dashboard updated"
}
This is a simplified representation of what Grafana stores. When you make a change and save, Grafana increments the version number and stores the entire dashboard JSON.
The problem Grafana solves here is version control for your monitoring interfaces. Before this, if you messed up a dashboard, you’d be staring at a blank screen or worse, incorrect data, with no easy way back. It’s like Git for your dashboards, but simpler.
Internally, Grafana uses a database (typically PostgreSQL or MySQL for newer versions, or SQLite for older/simpler setups) to store dashboard definitions. Each time you save, a new row or record is created, linking to the previous version. The history you see in the UI is just a frontend rendering of these saved states.
To restore a previous version, you navigate to your dashboard, click the "Settings" (gear icon), then "History." You’ll see a list of versions with timestamps and who made the change.
Here’s how you’d restore version 3 of "My Critical Metrics" (assuming it’s listed as an option):
- Open the dashboard you want to restore.
- Click the "Settings" (gear icon) in the top right.
- Select "History" from the left-hand menu.
- You’ll see a list of versions. Find the one you want (e.g., Version 3).
- Click the "Load" button next to that version.
- Grafana will show you a preview. If it looks correct, click "Restore."
This action doesn’t overwrite the current version immediately. Instead, it loads the content of the selected historical version into the dashboard editor. You then have an opportunity to save it, effectively creating a new, current version that matches the restored state. If you decide not to save, your current changes are lost, but the historical record remains.
The most surprising thing is how granular the history can be. Even minor changes, like moving a panel or changing a graph’s color, generate a new version. This is great for tracking down exactly when something broke, but it can also lead to a very long history list if you’re making many small edits in a single session without saving frequently. You can also view the diff between versions to see exactly what changed, which is incredibly useful for understanding regressions.
The next concept you’ll likely encounter is managing dashboard permissions and how they interact with version history.