Direct answer
The edits are lost because Grafana's provisioner treats the YAML file as the authoritative definition and rewrites the database row at startup. With the default allowUiUpdates: false, any change made in the UI is discarded on the next restart unless the file itself is updated.
Confirmed behavior vs. likely explanation
Confirmed: When allowUiUpdates is false (the default), Grafana reloads the dashboard from the file on startup and overwrites the stored database version. When allowUiUpdates is true, UI edits are written to the database and survive restarts, but a subsequent change to the source file—or deletion of the file—causes the file version to win again.
Likely explanation: The loss is silent because the provisioning engine performs the overwrite during startup without presenting a conflict dialog or warning banner in the UI. The database row is simply replaced, so the user sees the old definition and no error.
Diagnostic signals for drift
Two independent sources reveal whether a provisioned dashboard has drifted from its file:
- Server logs. At startup, Grafana emits provisioning messages. Look for lines similar to
Loading dashboard from file <path> and Overwriting dashboard UID <uid> with file version. If your log level is below info, these events may be suppressed; raise the level temporarily to confirm.
- Database state. Compare the dashboard's
version and updated timestamp in the dashboard table with the file's last-modified time. A database timestamp that is older than the file mtime after a restart, or a version number that resets, indicates the file has overwritten the UI state.
SELECT uid, version, updated
FROM dashboard
WHERE uid = '<uid>';
How allowUiUpdates interacts with restarts
The setting changes what happens to the database row, not whether the file is read:
| Setting | UI edit persistence | Restart outcome |
|---|
false (default) | Not persisted beyond restart | File definition overwrites DB row |
true | Persisted in database | DB row survives restart unless file content changes or file is removed |
Version note: Provisioning internals and log wording have changed across Grafana major releases (notably around the 7.x transition). Verify the exact semantics for your deployed version.
Duplicate UID load order
When two provisioning files declare the same UID, Grafana processes directories in lexicographic order by full path. The file processed last wins, making the outcome deterministic for a given directory layout. However, adding, removing, or renaming files changes the lexical sequence, so the winning definition can change without any edit to the file contents themselves.
Verification steps
- Inspect startup logs for the provisioning messages above.
- Run the SQL query against the
dashboard table and compare timestamps with the filesystem.
- If the behavior is still unclear, temporarily set
allowUiUpdates: true, make a UI change, restart, and confirm whether the change persists.
- To confirm UID collision ordering, place two files with the same UID in sibling directories, restart, then rename one directory and restart again to see which definition loads.
One detail that changes the recommendation
If you are not running a recent Grafana 7.x or later release, the exact log strings and the persistence guarantees above may differ. Please confirm your Grafana major version so the guidance can be scoped correctly.
grafana