Obervability
Services AudiTrace Resources▾ Contact
Dynatrace audit

What a Dynatrace audit finds — and what it costs you not to run one.

An audit reads your tenant end to end and reports what is actually configured, what is actually monitored, and what each of those choices is costing per year. One run, read-only, with the source behind every line.
Book a free audit See the 79 checks

What a Dynatrace audit is

A Dynatrace audit is a systematic, read-only review of a Dynatrace tenant: its configuration, its monitoring coverage, its alerting behaviour, its data retention and its consumption. It answers three questions a dashboard cannot — is everything that matters actually monitored, would a real incident actually reach a human, and what is each of those choices costing per year.
The distinction matters. A dashboard reports the state of what it was pointed at. An audit reports what it was never pointed at: the Full-Stack host with no monitored service on it, the alerting profile that was deleted while notifications still reference it, the retention nobody chose. Those are absences, and absences do not appear on a chart.
It is also not a support ticket or a health check in the vendor sense. 0 write scopes - read-only checks - a run changes no configuration. No finding arrives as an opinion — each one carries the exact source behind it, the list of objects it matched, and, where it can be computed, its annualized cost on your own rate card. All of it is done with AudiTrace, a tool we built for the job, which runs the same 79 checks in the same order on every tenant — so the result is a function of what you have, not of who looked and on which day.

Six signs it is time to run one

None of these are unusual. Most tenants collect several of them within two years of going live, because the people who made the original decisions have moved on and the decisions have not.

The bill grew faster than the estate

Host count went up 20% and the invoice went up 60%. Something other than growth is consuming — usually retention, ingest, or hosts running a mode nothing on them needs.

Nobody can say why a host is Full-Stack

The mode was set at rollout, by a template, and never revisited. Some of those hosts have no monitored service on them at all.

Incidents are still found by customers

Alerts fire, and yet the first report comes from outside. Usually maintenance windows, anomaly-detection overrides, or notifications pointing at a profile that no longer exists.

An admin left, and the tokens stayed

Nobody has an inventory of what tokens exist, what scopes they hold, or which of them have not been used in a year.

A renewal or a DPS move is coming

You need a defensible number for the negotiation, not a vendor estimate, and you need it tied to objects you can point at.

Retention was set once, in a hurry

Default buckets are generous. A default left in place for two years is one of the largest single line items we find, and it was never a decision.

What it covers — 19 domains, 79 checks

A check that cannot run reports blocked or not applicable. It never reports a pass it could not prove.
DomainChecksWhat it answersExample
FinOps13Where the money goes, and what is recoverableFull-Stack hosts with no monitored service behind them — 140 of them, $91,576 a year
Kubernetes11Cluster coverage, versions, recurring failuresA cluster whose operator was left behind by an upgrade, and stopped reporting quietly
Alerting9Whether an incident would actually reach a humanMaintenance windows left permanently open — 1,617 of them, suppressing alerts
Audit log7Who changed what, when, and outside business hoursA configuration change made outside business hours by an account that has since left
Coverage5What is monitored, what only looks monitoredA namespace that reports workloads but no pods — monitored on paper, blind in practice
RUM4Real-user monitoring reach and privacy settingsApplications with no traffic for 90 days — 86 of them, still licensed and configured
Grail4Buckets, retention, annualized storage costThe default metrics bucket still at 462 days, because nobody ever chose otherwise
Pipelines3Ingest processing, masking, drop rulesLog sources carrying e-mail addresses in cleartext — 50 of them, with no masking rule
Synthetic3Synthetic monitors that pass, fail, or never runA monitor that has not run since the location it used was retired
Topology3Entity detection quality and entity explosionOne service carrying hundreds of historical versions, so Davis has no continuity to reason over
OpenTelemetry2OTel sources and dual instrumentationA service instrumented twice — once by OneAgent, once by OTel — and counted twice
Security2Token scopes, expiry, dormant credentialsA token with write scope that nobody has used for a year, issued by someone who left
Workflows2Automation that fails or never firesAn automation that has failed on every run for months, with nothing watching it
Bizevents1Business event provider hygieneAn event provider sending fields that no dashboard and no query ever read
Dashboards1Dashboard inventoryA dashboard nobody has opened in a year, owned by an account that no longer exists
Davis1Root-cause attribution rateProblems closing without a root cause attributed, so the same incident recurs unexplained
OpenPipeline1Route and pipeline resolutionRecords landing on the default route, unenriched, because the rule that should have caught them was never applied
SLO1SLO definitions that break on re-detectionAn SLO whose definition stops matching after a re-detection, and quietly reports nothing
Tagging1Environment tagging conventionHosts with no cost-allocation tag — 384 of them, so no team can be charged for them

What one audit found

One customer, a very large shipping company, anonymized: several thousand hosts, 100+ applications, multiple Kubernetes clusters. In that run, 75 of 79 checks completed; 4 were blocked by server-side constraints and reported as blocked.
FindingScaleAnnual impact
Full-Stack hosts with no monitored service140 hosts$91,576 / year
Default metrics bucket at 462 days retention1 bucket$22,455–$86,115 / year
Permanent or expired maintenance windows1,617Alerting silently suppressed
Hosts without cost-allocation tags384Chargeback impossible
Anomaly-detection overrides disabling alerting106Detection off at entity level
RUM applications with no traffic in 90 days86License and configuration waste
Log sources with email addresses in cleartext50 sources · ~30.7M/dayGDPR exposure
Computed with that client’s negotiated rate card, not list price. The range on retention reflects a decision that was theirs to make. A cost is never added to a saving.

What you actually receive

Not a slide deck. A finding is the unit of work, and every one of them has the same four parts.

The annual cost

Priced on your negotiated rate card. A cost is never added to a saving.

Business value

What the finding means in your own terms — what it saves, what it exposes, and what it costs to leave alone.

The object list

Every affected entity, as a CSV. Not a count — the actual rows.

The verdict

Every one of the 79 checks comes back with a status of its own — pass, fail, blocked or not applicable. A check that cannot run never reports a pass it could not prove.

How it runs

Runs from a workstation, or inside the tenant

AudiTrace is an engine that runs from a workstation, or an app inside the customer’s tenant.

Read-only, by construction

0 write scopes - read-only checks - a run changes no configuration.

Your team can run it instead

The same engine ships as a native Dynatrace app. Every check declares both routes and returns the same verdict either way, so nobody outside your organisation has to connect at all.

Log content is never read

Queries against logs, spans and business events return counts and field names. Message bodies and payloads are not retrieved, and not stored.

Questions we get asked first

How long does a Dynatrace audit take?

One run. The engine completes on its own; reading the findings and agreeing what to do about them takes a meeting. There is no discovery phase and no questionnaire.

Does it need write access to our tenant?

No. 0 write scopes - read-only checks - a run changes no configuration.

Is this a Dynatrace product?

No. AudiTrace is ours. It uses documented APIs and DQL, the same interfaces your own team has, which is why every finding can be reproduced without us.

What does the first audit cost?

Nothing. The first run is free and you keep the report regardless of whether you engage us for anything afterwards.

Will it slow the tenant down?

The engine issues ordinary read queries, and where a server-side cap stops one, the check reports blocked rather than retrying against your environment.

What happens to a check that cannot run?

It reports blocked or not applicable, and says which. A check never reports a pass it was unable to prove — four of the 79 in that run came back blocked on the tenant in the case study, and the report said so.

Run it on your own tenant.

The first audit is free, it is read-only, and the report is yours either way.
Book a free audit See how AudiTrace works

Find out what your observability 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
After you send this, we reply within one business day. Next is a short scoping call. The audit is read-only, and you keep the report.
Obervability
Dynatrace implementation, managed services and support. Every finding comes with the source behind it.
© 2026 Obervability · All rights reserved.