Obervability
Services AudiTrace Resources▾ Contact
Book a free audit
Audit domain · 7 checks

Dynatrace audit log review: who changed what, and when

Seven checks on the tenant’s own audit log — configuration changes by actor, changes made outside business hours, deletions of monitoring configuration, and activity from tokens rather than people.
Book a free audit All 71 checks

What these checks read

Change volume by actor

Who is changing configuration, how often, and whether the top actors are people, service accounts or automation.

Out-of-hours configuration changes

Changes made outside working hours, by actor. Not a violation in itself — a question worth being able to answer.

Deletions

Deleted alerting profiles, management zones, dashboards and monitoring settings, with the actor and timestamp for each.

Token-driven activity

Changes made by API tokens, mapped back to the token and its owner where the token still exists.

Why it matters

Most tenants have never read their own audit log. It is there, it is retained, and nothing routes it anywhere, so the first time anyone opens it is during an incident review — which is the worst moment to discover that the change that caused the outage was made by a token whose owner left last year.
This domain is deliberately descriptive rather than prescriptive. It produces the shape of change in your tenant: who, what, when, and through which credential. Where that shape is surprising — a service account making settings changes at 03:00, a burst of deletions on one afternoon — the finding hands you the rows and lets you decide whether it was routine.
It also underpins every other domain. When the FinOps checks find a bucket at 462 days of retention, the audit log is what answers the next question: nobody chose it, or somebody did, on a date, for a reason that may still apply.

Questions we get about this domain

How far back can the audit look?

As far as your tenant retains its audit log — typically the last 90 days on Grail-backed tenants, less on older configurations. The report states the window it actually read rather than implying a longer one.

Is reading the audit log itself logged?

Yes, and that is the point: the audit runs under a named token you issue and revoke, so every read it performs is attributable to you in your own log. Nothing about the audit is invisible to the tenant owner.

The other audit domains

Nineteen domains, 71 checks, one read-only run. Each domain is a page.
FinOps Where the money goes, and what is recoverable Kubernetes Cluster coverage, versions, recurring failures Alerting Whether an incident would actually reach a human Audit log Who changed what, when, and outside business hours Coverage What is monitored, what only looks monitored RUM Real-user monitoring reach and privacy settings Grail Buckets, retention, annualized storage cost Pipelines Ingest processing, masking, drop rules Synthetic Synthetic monitors that pass, fail, or never run Topology Entity detection quality and entity explosion OpenTelemetry OTel sources and dual instrumentation Security Token scopes, expiry, dormant credentials Workflows Automation that fails or never fires Bizevents Business event provider hygiene Dashboards Dashboard inventory Davis Root-cause attribution rate OpenPipeline Route and pipeline resolution SLO SLO definitions that break on re-detection Tagging Environment tagging convention

See what this domain finds on your own tenant.

One read-only run covers all nineteen domains. You keep the report either way.
Book a free audit See how AudiTrace works

Find out what your Obervability is actually doing.

An audit takes one run. The findings take one meeting. What you do with them is up to you.
Certified Dynatrace experts
+1
Send
Obervability
Dynatrace implementation, managed services and support. Every finding comes with the source behind it.
Services
Services AudiTrace Case study
Guides
Dynatrace audit Dynatrace cost optimization Audit case study Articles
Reach us
© 2026 Obervability · All rights reserved.
Privacy Terms of use Accessibility