16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs

A dashboard only helps the people who open it. The Reporting and Analysis topic covers the two mechanisms that push Dynatrace insight to people and systems that will never log in: scheduled reports and APIs.

---

Dashboard Reports and Subscriptions

Dashboard reports exist so that a service owner, a finance stakeholder, or a compliance reviewer can stay current without a Dynatrace login habit. Anyone with access to a dashboard can subscribe to Weekly, Monthly, or both, and the mechanics are specific enough to be tested directly:

Two of those lines are the ones candidates get wrong. First, the email is a link, not an attached rendering — the recipient opens report content for a fixed timeframe, not a frozen image. Second, because that link is viewable anonymously, enabling reports is a data-exposure decision: whoever holds the URL sees whatever the dashboard shows. Subscribing a broad distribution list to a dashboard containing customer identifiers is a privacy incident waiting to happen (Chapter 17).

Report subscriptions in this form are a Dashboards Classic capability. In the latest Dynatrace the Dashboards app is the successor surface, and scheduled delivery is built with Workflows: a schedule trigger plus a Send email task. The details there are also concrete — the action needs the email:emails:send permission, mail is sent from no-reply@apps.dynatrace.com, each of the To, Cc, and Bcc fields accepts at most 10 addresses, and trial environments are blocked from sending. A simple workflow (a single task, such as that one email) consumes no workflow hours, although a DQL query run inside it still generates query usage.

The design guidance that follows is worth internalizing because scenarios test it:

• A report is a snapshot, not a monitoring tool. Anything that needs a response within hours belongs in an alerting profile (Chapter 8), not in a weekly email.
• The dashboard that makes a good report is usually not the dashboard the SRE debugs with. Reports should lead with trend and outcome; debugging dashboards lead with detail.
• Subscriptions are per-recipient, so the distribution list is maintained in Dynatrace rather than in a mail client rule.

---

Programmatic Access: The API Families

Which of the first two you reach for follows from which dashboarding generation you are on: the Dashboards API belongs to Dashboards Classic, while a dashboard in the latest Dynatrace is a document and is managed through the Document API, where it is listed with the type DOCUMENT_DASHBOARD. The framing to remember either way is that Dynatrace is not intended to be a closed system.

---

Authentication: OAuth Clients

The modern Dynatrace platform authenticates programmatic access using an OAuth client rather than the legacy environment API token. An OAuth client is created in account management with a defined set of scopes — for example storage:logs:read or document:documents:write — and the calling system exchanges its client credentials for a short-lived bearer token.

The security properties that make this the right answer in scenarios:

• Scoped: a reporting integration can be granted read-only access to exactly the data types it needs.
• Short-lived tokens: a leaked bearer token expires, unlike a long-lived static API token.
• Auditable: calls are attributable to a named client.

Scopes are granular and map onto the Grail tables directly: storage:logs:read permits fetch logs, storage:metrics:read permits timeseries, and document:documents:read permits pulling a dashboard definition. A reporting integration that only charts metrics has no business holding log-read permission.

Platform Tokens

OAuth clients are not the only supported route. Platform tokens are long-lived platform access tokens that an ordinary user can create without administrator involvement, and they operate strictly within the bounds of that user's permissions — or those of a service user the creator has access to.

A platform token is presented like any bearer token — Authorization: Bearer <token> — and an expired one returns HTTP 403. Dynatrace names exactly the use cases this chapter covers: running a scheduled Grail query for data export and ETL, ingesting business events by API, and keeping dashboards in sync across multiple environments.

So the exam-relevant contrast is not "OAuth good, token bad" — both are current platform mechanisms. What is always wrong is a broadly privileged personal login shared between systems, and whichever mechanism you choose should be reduced to the narrowest scope that does the job.

---

Dashboards as Code

A dashboard in the latest Dynatrace is a JSON document — four required properties, version, variables, tiles, and layouts, plus optional settings and annotations — which is precisely why it round-trips through a repository cleanly. The definition can be downloaded straight from the dashboard's menu or retrieved through the Document API, so dashboards and notebooks can be treated as source-controlled artifacts:

1. Export the dashboard definition.
2. Commit it to the repository alongside the service it monitors.
3. Review changes through the normal pull-request process.
4. Deploy it into development, staging, and production tenants from the same definition.

Three problems disappear: dashboards drifting between environments, an accidental edit destroying a board with no way to recover it, and no record of who changed a threshold or why. Exam scenarios that mention "a dashboard was accidentally modified and we cannot restore it" are pointing at this practice.

---

Feeding External Systems

When a data warehouse, BI platform, or executive reporting system needs Dynatrace data, the supported route is the Grail — DQL Query API: the external system issues the same DQL you would write in a notebook and consumes the returned records. You can only query through this API, never ingest.

The call is deliberately asynchronous, because a Grail query spanning months does not return within a single HTTP round trip:

1. POST /query:execute carries the DQL in the request body — for example {"query": "fetch bizevents | summarize count()"}. The response returns a state and a requestToken.
2. GET /query:poll, passing that requestToken, retrieves the result once the state reports SUCCEEDED.

An integration written as a single synchronous call will appear to work against a two-hour query and then time out against a ninety-day one — a failure mode that surfaces in production rather than in testing.

Design rules that appear in scenarios:

• Query aggregates, not raw records. Pulling millions of raw log lines nightly to compute a count externally is wasteful when summarize returns the count directly.
• Respect retention. An external system cannot retrieve data Dynatrace no longer holds, so anything needing a longer horizon than Dynatrace retention must be exported on a schedule before it ages out (Section 16.1).
• Do not rebuild alerting externally. Exporting metrics so a third-party tool can threshold them discards Davis causation and seasonal baselining — the exam's preferred answer is to alert in Dynatrace and export the result.