Grafana audit logs and change tracking

Why Grafana audit logs matter for access and change tracking

When an auditor, security team or incident responder asks who logged in to Grafana, who edited a dashboard, data source or alert rule, and when, the answer has to come from a record that was written at the time of the event and that the people being investigated could not quietly alter. A usable change history answers four questions for every sensitive action: who acted, what object they touched, what changed, and when it happened. Without those answers, an incident review tends to become a debate about memory, and a compliance assessment has little to point to beyond a statement that the team does not make unauthorized changes. Grafana holds dashboards, data source connections and alert routing, so a silent change to any of them can redirect alerts, expose data or hide a fault.

Audit logging is an Enterprise capability. The open-source edition does not give you a dedicated audit event stream, so an open-source team cannot simply switch on a setting and export a complete record of administrative actions. Before you commit to an open-source design, confirm the current audit feature list for each edition on the Grafana licensing page and in the Grafana documentation for your target version, because the boundary between editions is the single fact that most changes the evidence you can produce.

The choice affects evidence quality more than it affects day-to-day use. In the open-source edition you will reconstruct changes from server logs, dashboard version history and your identity provider's sign-in records, and each source covers a different part of the question. Gaps are likely in areas such as failed sign-ins, permission changes and data source edits, so decide which questions your auditors and responders must be able to answer, then test whether your chosen sources answer them before an incident forces the test. The rest of this section sets out what those questions require.

Which audit events each edition gives you

Grafana Enterprise is the edition that provides built-in audit logging, so it is the starting point if you need recorded evidence of who changed what inside Grafana. The edition is licensed separately, and the Grafana Labs licensing page explains how it differs from the open-source offering. Verify the exact event list against the current Enterprise documentation for your version before you write any event into a control matrix.

Who configures it: the platform team enables audit logging in the Grafana configuration after the Enterprise license is installed.
Evidence to expect: records of user and API actions that change Grafana objects, with the exact coverage confirmed for your version.
Where events go: confirm whether events are written to a local file, sent to a log pipeline such as Loki, or both, and who holds read access.
Gaps to test: authorization decisions, data source credential changes, folder permission changes and API key use may or may not be recorded, so test each one.
Retention and integrity: the audit store is yours to keep, so set retention and access controls to match your evidence period.

Before you rely on this evidence, make one test change per action category in staging and confirm the event appears with the user, time and object changed.

The open-source edition does not offer a dedicated audit event stream. Grafana server logs record request activity, login attempts and errors, which can show some access patterns but usually do not describe the change itself. Treat them as supporting evidence rather than a complete record of configuration changes.

What it shows: request-level entries for HTTP access, login activity and errors, with detail depending on the configured log level.
Who configures it: the platform team sets the log mode, level and file location in the [log] section of grafana.ini, and should confirm the key names for the installed version.
Where it goes: logs are written to files or standard output, so shipping them to a central store is your responsibility, often through Grafana Alloy into Loki.
Gaps to close: server logs rarely name the dashboard, folder or data source that changed, and authorization decisions may be absent unless logging is set to a detailed level.
Volume and cost: verbose logging adds noise and storage use, so tune the level before enabling it across the whole instance.

Before you accept these logs as access evidence, check a sample against a known login and a known permission change to confirm they appear.

Audit log destinations and configuration options

This table compares three ways to store Grafana audit events: local files, direct shipping to Loki, and a collector such as Grafana Alloy feeding a central store. Read each row against who will operate the store and who will answer for retention, since those responsibilities differ most between options.

Option	When it fits	Operations and retention responsibility	Main trade-off
Local files on the Grafana host	Small teams without a central log platform, or a first step while the destination is decided	Your Linux team owns rotation, disk capacity, permissions and retention. Nothing is kept beyond what the host and rotation policy allow.	Simple to set up, but a host-level attacker or disk failure can remove events. Hardening file ownership and forwarding copies off-host are needed for assurance.
Direct shipping to Grafana Loki	Teams that already run Loki for logs and want audit events queryable in the same Grafana	Your observability team owns the Loki cluster, object storage and the authenticating proxy. Retention must be set explicitly because it is disabled by default.	Strong query experience, but Loki adds components to run, and it has no built-in authentication so a reverse proxy must front it.
Collector (Grafana Alloy) to a central store	Organizations with several log sources, or where audit events must go to a SIEM or a store other than Loki	Your platform team owns the collector pipeline and the destination. Retention depends on the central store, so confirm it in writing with the store owner.	More moving parts and delivery settings to verify, but it separates collection from storage and keeps one shipping path for all systems.
Retention setting in Loki	Any Loki destination where events must be kept for a defined period	Loki retention is applied by the compactor and is disabled by default, so logs are kept indefinitely until retention_enabled is set.	Set retention per tenant or per stream selector deliberately, with each stream rule at least 24 hours. Test deletion behaviour before relying on it.
Multi-tenancy in Loki	Shared Loki clusters where audit events must be separated from application logs	Loki is multi-tenant when auth_enabled is true and identifies tenants with the X-Scope-OrgID header on every request.	Each sender and reader must set the correct tenant header. A missing header can misplace or hide events, so verify tenant routing end to end.
Authenticating reverse proxy	Every Loki deployment, because Loki has no built-in authentication layer	Your security or platform team owns the proxy (for example nginx, HAProxy, OAuth2 Proxy or Pomerium) and its TLS and access rules.	Without it, anyone who can reach the Loki endpoint can read or write audit data. Confirm proxy settings against the Loki authentication docs.
Audit-specific configuration keys	Any destination, when you need to turn audit logging on and choose its output	Confirm the exact audit keys and whether audit logging is available in your edition in the Grafana Enterprise documentation.	Do not assume open-source keys cover audit events. Record the verified key names and the Grafana version they were tested on.

Setting up audit log shipping step by step

This sequence moves Grafana audit events through a collector into a tenant-scoped Loki store. Each stage ends with a check, so you can confirm that access and change records arrive, persist across restarts, and stay readable only by the people who should see them.

Confirm the edition and license terms
The platform owner checks which Grafana edition is running and whether audit logging is part of that edition's feature set. Audit logging is treated as an Enterprise capability, so confirm the current feature list in Grafana Labs documentation and the Grafana Labs licensing page before you design around it. Record the exact Grafana version, since configuration keys and upgrade behavior depend on it. The step is complete when the edition, applicable license terms and version are written down and shared with the team that will own the audit store.
Choose the destination and tenancy model
Decide whether audit events go to local files, to Loki, or to both, and whether they share a Loki tenant with application logs. A dedicated tenant ID for audit data makes access control simpler later, because Loki identifies tenants with the X-Scope-OrgID header when multi-tenancy is enabled. Also agree on the labels every event will carry, such as environment, Grafana instance and log type, and keep that label set small. The step is complete when the destination, tenant ID and label list are documented in a short diagram that the security and platform teams both approve.
Enable audit output on every Grafana node
The platform engineer enables the auditing settings in the Grafana configuration file and confirms the exact key names and output options in the Grafana documentation for your version. High availability runs two or more active-active Grafana servers on a shared MySQL or PostgreSQL database, so configuration and data are shared, but each node writes its own audit output. Deploy the same settings to every node through your configuration management, then restart. The check is one test action that produces an audit event on each node, confirming that no node was missed and that output is consistent across the cluster.
Route audit events through the collector
The platform engineer configures Grafana Alloy, Grafana Labs' supported log shipper for Loki, to read the audit output from every node. The collector attaches the labels agreed earlier and sends each batch to Loki with the audit tenant ID. Keep the pipeline simple, avoid parsing that creates many unique label values, and run the collector under a service account with only the permissions it needs. The check is to view the collector's debug output or a sample push and confirm that each event carries the expected tenant, labels and original timestamp.
Set Loki retention and compactor settings
The platform engineer confirms that Loki stores its chunks and index in object storage, with TSDB as the index store, and then enables retention in the compactor. Retention is disabled by default, so logs are kept indefinitely until retention_enabled is set. Retention can apply globally, per tenant or per stream selector, and each stream rule must be at least 24 hours. Agree the retention period with the compliance owner before you set it. The check is that compactor logs show retention runs and that a test entry older than the configured period is removed.
Place an authenticating proxy in front of Loki
Loki has no built-in authentication layer, so the platform engineer places an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. The proxy should authenticate the caller and set the tenant header itself, so users cannot choose which tenant they query. Close direct network access to the Loki ports. The check is that an unauthenticated request is rejected, an authenticated request for the audit tenant succeeds, and a request for another tenant through the proxy is refused.
Restrict who can read audit data
The Grafana administrator creates a Loki data source for the audit tenant and limits its access to a named audit reader group. The security owner reviews who holds Grafana administrator rights, because administrators can change data source settings and permissions. Keep the reader list short and documented, and review it on a set schedule. The check is to sign in as a standard user who is not in the audit group, confirm that the audit data source is not visible or queryable, then repeat the test with an audit reader and confirm access works.
Test with a known change and confirm persistence
The Grafana administrator makes a known, low-risk change, such as creating a test dashboard, and notes the user and time. In Grafana Explore, the audit reader queries the audit tenant using the agreed labels and a time range around the recorded time, then confirms that the user, action and timestamp match. Restart Grafana on each node, run the same query again, and confirm the test event is still there. Also check that the event appears once, with no duplicates from the cluster. Keep the test record as evidence that the pipeline works end to end.

How open-source teams reconstruct changes without audit logs

On the open-source edition, the practical method is to correlate three records: Grafana server logs, dashboard version history and your as-code repository. Server logs can show login attempts and API request lines with timestamps and, where Grafana logs them, user identifiers. Dashboard versions show who saved which change and when, and you can compare any two versions to see what moved. Alert rule changes should be traced through the same repository history, so that a question such as "who changed this threshold last month" has more than one source to check against. Confirm the exact fields your server log format writes in your own version before you build a report on them, because the set of fields is the first thing an auditor will ask about.

The gaps need to be stated plainly to the assessor. Server logs may not record every field an auditor expects, such as the object changed, the prior value or the source address for every action, so treat them as supporting evidence rather than a complete trail. Log retention is your responsibility: Grafana writes logs according to your own configuration and rotation, so you must confirm where they are shipped, how long they are kept and whether anyone can delete them. Dashboard versions also do not prove who viewed data. A version history tells you what was saved, not which person opened a panel or queried a data source, and that visibility question needs a different control.

The strongest change record available on the open-source edition is provisioning. The Grafana provisioning documentation describes defining data sources, dashboards, plugins and alerting resources in YAML or JSON files that load at startup, so each change arrives as a reviewable commit with an author, a reason and a diff. Where the team can adopt provisioning, or the Git Sync option that the same documentation mentions, move dashboards and alert rules into Git first and make manual edits in the UI the exception. Decide who may merge to the production branch, and record that approval rule in your change process. This approach does not replace access logging, but it makes the change history much easier to defend.

Protecting audit trails from tampering and overexposure

Audit records are only useful if the people they describe cannot quietly change them and the logs do not leak what they should protect. The controls below cover where audit output is stored, who can read it, how the Loki write path is protected, what gets written into log lines, and which Grafana settings change what is logged or exposed.

Separate storage and administration for audit output

Send audit output to a destination that the Grafana administrators cannot edit, such as a log platform run by a separate team or object storage with object lock or versioning enabled. Grafana writes its own audit events, so anyone with host access to the Grafana server can alter or delete local audit files. Confirm with your storage vendor which immutability features are available and how retention holds are applied. Grafana does not add tamper-evidence to the files it writes.

Restrict read access to the log platform

Audit events show who viewed or changed dashboards, data sources and users, so the log store itself becomes sensitive. Limit query access to the security and platform teams and review who holds it. Loki has no built-in authentication layer, so the query path needs an authenticating reverse proxy in front of it. Check that Grafana's own data source users cannot query the audit tenant unless that is intended.

Protect the Loki write path and tenant headers

Loki is multi-tenant when auth_enabled is true and identifies tenants with the X-Scope-OrgID header on every request. If a client can set that header, it can write audit events into another tenant or read logs it should not see. Require the header to be set by the authenticating proxy rather than the client, restrict which services can push to the audit tenant, and test that a request with a different tenant value is refused.

Keep sensitive values out of log lines

Audit records and shipped server logs can capture query text, URLs, tokens or user-supplied fields that contain credentials or personal data. Review what your collector and Grafana's log output include, and drop or mask fields before they reach a shared store. Anyone with read access to the audit tenant then sees only what they need. Ask your team to test a sample of shipped events for secrets before go-live and after any dashboard or data source change.

Synchronize time across all nodes

Reconstructing a change sequence depends on timestamps that agree across the Grafana servers, the database, the collector and Loki. Clock drift can place a permission change after the event it authorized, which weakens any investigation. Run a managed time service on every node, monitor its offset, and record the time source in your runbook. Confirm the timezone and format used by each component so events line up when merged.

Review hardening settings that change exposure

The security hardening guidance covers settings that affect what is exposed and what a browser or unauthenticated visitor can see, including secure and SameSite cookies, a Content Security Policy, hiding the version from unauthenticated users, requiring authentication for the metrics endpoint and domain verification against DNS rebinding. Review these settings with your audit scope in mind, because a session that is easy to hijack produces audit records that name the wrong person. Record each setting value in change control.

Questions teams ask before adding audit logging

Can the open-source edition of Grafana produce audit logs?

The open-source edition does not provide the Enterprise audit logging feature, so teams on it reconstruct access and change history from other records. The main sources are Grafana server logs, dashboard version history and any logs you ship to a central store. This approach can support many internal reviews, but it depends on what each source records, how long it is kept and whether someone can connect a login to a specific change. Confirm the current split between editions in Grafana's documentation before you design around it, because feature availability can change between releases.

What does the Enterprise license change for audit logging?

The Enterprise license adds the audit logging capability and is offered as a non-AGPL commercial option, separate from the AGPLv3 terms that cover the open-source edition. Check the Grafana Labs licensing page for the current terms before you plan. The public pricing page lists an Enterprise tier with a 25,000 US dollar minimum annual commitment, but that tier belongs to Grafana Cloud, so it does not price a self-managed Enterprise license. Ask Grafana Labs for a written quote covering your node count, support level and term, and ask which audit events are included and how they are delivered.

How long does audit logging setup take, and what drives effort?

No fixed duration can be given from the supplied facts, so any timeline depends on scope. The main drivers are the Grafana edition, the maturity of your log platform, the number of Grafana nodes and your retention requirements. A single instance that already ships logs to a running Loki deployment is a smaller change. A high-availability setup with two or more active-active servers behind a load balancer, a new Loki deployment and an authenticating reverse proxy needs more design and testing. Retention and access rules add review time, because owners must agree on them before the build starts. Ask for the work to be split into phases with written acceptance checks.

Can our own team set up audit logging internally?

Yes, if the team already runs Grafana and Loki in production and can operate both. The work touches Grafana configuration, log shipping, object storage, a reverse proxy and retention settings, so the people involved need to be comfortable with each. Loki has no built-in authentication layer. Its authentication documentation says to place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it, and teams new to Loki often miss this. Grafana Alloy is Grafana's supported log shipper for Loki, so check how it is configured to collect Grafana's own logs. A written design review before building is often the most useful step for teams without this background.

What must our organization provide before audit logging work starts?

Most teams must provide log storage, a reverse proxy, a retention policy, named owners and access to the environment. The list below shows what to prepare:

Log storage: an object store for Loki. Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production options.
Reverse proxy: an authenticating proxy in front of Loki, integrated with your identity provider.
Retention policy: the audit event retention period, approved by the people accountable for it.
Owners: named owners for Grafana, Loki, the log store and the policy, with on-call contacts.
Environment access: access to the Grafana database, hosts, networks and change records where the work runs.

How long should audit events be kept in Loki?

Retention is a policy decision, and Loki does not set one for you. Loki retention is disabled by default, so logs are kept indefinitely until retention_enabled is set for the compactor. Retention can apply globally, per tenant or per stream selector, and each stream rule must cover at least 24 hours. Set the period from the obligations your organization must meet, and have compliance, legal and the security owner sign it off before you configure it. Keep audit streams in their own tenant or selector so that a shorter rule for debug logs cannot remove them. The Loki retention documentation covers the configuration keys.

Does DeployOpen agree the audit logging scope in writing first?

Yes. Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. For audit logging, the written scope should name the Grafana edition, the number of nodes, the log platform, the reverse proxy, the retention rules and the owners who accept each control. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies do that work. A quote follows from the written scope, and DeployOpen does not publish a price list.

Limits to confirm in your environment

Audit logging for Grafana depends on the edition, the version, the database layout and the log platform you run around it. The items below are the points to confirm with Grafana Labs or test in your own environment before you design access and change tracking around them.

Audit event coverage by version

Confirm exactly which access and change events your Grafana version writes to its audit log, including logins, dashboard edits, permission changes, data source changes and API calls. Coverage differs between releases, so the list you rely on should be taken from the documentation for the version you run, not from memory or from a newer release. Ask Grafana Labs in writing which events are covered for your edition, and test each one by performing the action in a non-production instance and checking the output.

Audit output in high availability

In a high availability layout, two or more active-active Grafana servers sit behind a load balancer, so each node writes its own audit output. Confirm whether audit events from every node reach one central store, how ordering is kept across nodes, and what happens to events when a node restarts. Check this with a failover test: generate events on each node, stop one, and confirm that no events are lost or duplicated in the central store.

Loki deployment mode and simple scalable status

Loki offers monolithic, simple scalable and microservices deployment modes, and the Loki documentation states that simple scalable mode is being deprecated and will be removed with Loki 4.0. If you plan a simple scalable setup for audit storage, ask how your migration path to another mode would work before go-live. Choose a mode based on your expected log volume and your team's operating capacity, and confirm the removal timing with Grafana Labs before you commit.

Loki version currency

The Loki GitHub releases page lists v3.7.8, published September 17, 2026, as the latest release supplied for this page. Check the release list on the day you plan, because a newer patch or minor release may exist by then. Confirm which Loki version your environment will run, whether it receives security fixes, and how upgrades will be tested against your audit retention and query workload before they reach production.

Object storage choice for production

Loki keeps compressed log chunks and its index in object storage. Amazon S3, Google Cloud Storage and Azure Blob Storage are the recommended production stores, while S3-compatible stores such as MinIO and the local filesystem are supported but not typically recommended for production. Confirm that your chosen store meets your durability, residency and access requirements, and ask your storage team how immutability or write-once settings, if you need them for evidence, would apply to Loki buckets.

Log volume against mode limits

The Loki documentation describes monolithic mode as suited to up to about 20 GB of logs per day, and simple scalable mode as approaching 1 TB per day. Measure the audit and application log volume you expect over a representative period, including peaks, and compare it with these limits before choosing a mode. Retention is disabled by default in Loki, so confirm that retention_enabled is set deliberately, because audit evidence kept indefinitely has its own storage and access implications.

Server logs as interim evidence

Server logs and dashboard version history can support a change record, but they may not satisfy every framework's expectation for audit evidence. Ask the auditor or compliance owner whether server-side logs, retained in a separate log platform, are acceptable as interim evidence for access and change tracking, and what they must show, such as who acted, when and what changed. DeployOpen prepares systems and evidence for assessments, but independent auditors decide whether the evidence is sufficient.

How DeployOpen scopes and delivers audit logging

DeployOpen plans, implements and documents Grafana audit logging inside your own infrastructure, starting from the access and change questions your auditors and security team need answered. The work is scoped in writing before it starts, and the same reconstruction method is documented for teams that stay on the open-source edition.

How we scope

Confirm your Grafana edition and whether Enterprise audit logging is licensed before choosing the event path.
Define which access events, dashboard and data source changes, and retention periods the written scope must cover.
Agree in writing where audit events are stored, who reads them, and which evidence the scope delivers.

How we build

Configure audit event output to Loki or local files, with Grafana Alloy or another shipper matched to your environment.
Set up Loki tenancy, authenticating access in front of Loki, and retention rules that match the agreed evidence period.
Test that sign-ins, role changes and dashboard edits appear in the audit store, and document the checks that passed.

How we hand over

Deliver runbooks for querying audit events, exporting evidence and rebuilding change history from server logs and dashboard versions.
Document the configuration, access model and retention settings so your team can operate the pipeline after handover.
Walk your operators through alerting on audit gaps, such as a stopped shipper or a missing tenant header.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can cover re-testing audit delivery after Grafana or Loki upgrades and after configuration changes.
Ask us to confirm which audit controls remain your responsibility, since DeployOpen prepares evidence but does not issue audit reports.

Grafana audit logs for access and change tracking