---
title: "Why Grafana as code | Grafana Labs"
description: "The problems with manual dashboard management and how code solves them"
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

## The problem with manual processes

Your team has 30 dashboards across staging and production. Someone tweaks a threshold in production on Friday afternoon, and by Monday no one remembers what changed or why. That’s **dashboard drift**: live dashboards silently diverging from their intended state. Manual dashboard management creates three recurring problems like this that grow worse as your team scales.

| Problem             | What happens                                                                                                                 |
|---------------------|------------------------------------------------------------------------------------------------------------------------------|
| **dashboard drift** | Anyone with edit access can change a dashboard in the UI with no review, so the live version diverges from what you intended |
| **Duplication**     | Teams copy dashboards instead of sharing one source; fixes don’t propagate                                                   |
| **No audit trail**  | You can’t answer “who changed what, when, and why” at scale                                                                  |

## How as code solves this

Managing dashboards as code means keeping dashboard definitions in version-controlled files instead of only in the UI. You gain:

- **Version control.** Every change is a Git commit with context.
- **Code review.** Pull requests catch mistakes before they reach production.
- **Automation.** A CI/CD pipeline can regenerate files so what’s in the repo stays the source of truth.
- **Recovery.** You can restore a known-good version from Git after a bad edit or accidental delete.