Study guide
16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs
Dynatrace Certified Associate Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Overview, Deployment Models & Architecture
1.1 Dynatrace Platform Capabilities, Web UI Navigation & the Dynatrace Hub 1.2 SaaS vs. Dynatrace Managed Architecture & Security 1.3 Core Telemetry Components: OneAgent, ActiveGate & Grail Lakehouse 1.4 Licensing Models: Dynatrace Platform Subscription (DPS) & Davis Data Units (DDUs)
2 Chapter 2: ActiveGate Architecture & Network Topologies
2.1 ActiveGate Types: Environment vs. Cluster ActiveGates 2.2 ActiveGate Capabilities: Proxying, Private Synthetic, Cloud Integrations & Extensions 2.3 Network Zones, Multi-DC Routing & Firewall Traversal
3 Chapter 3: OneAgent Deployment, Configuration & Management
3.1 OneAgent Architecture, Components & Automatic Injection 3.2 Host Installation on Linux, Windows & Containerized Hosts 3.3 Cloud-Native Deployment: Dynatrace Operator on Kubernetes & OpenShift 3.4 Kubernetes Observability: Clusters, Nodes, Namespaces, Workloads & Events
4 Chapter 4: Monitoring Modes, Process Groups & Infrastructure Observability
4.1 Monitoring Modes: Full-Stack vs. Infrastructure-Only vs. Discovery 4.2 Process Groups, Process Instances & Custom Process Group Detection Rules 4.3 Host Groups, Host Naming Rules & Environmental Metadata Extraction 4.4 Infrastructure & Operations: Host Health, Disk, Network & Availability Analysis 4.5 Database Observability: The Databases App, Connection Pools & Storage Latency
5 Chapter 5: Smartscape Topology & Service Flow
5.1 The 5-Layer Smartscape Topology: Datacenter to Application 5.2 Service Detection: Web Services, Background Tasks & Custom Services 5.3 Service Flow, Backtrace Analysis & Horizontal/Vertical Dependency Mapping
6 Chapter 6: PurePath Distributed Tracing & Code-Level Diagnostics
6.1 PurePath Architecture, Distributed Tracing & Request Context Propagation 6.2 Method Hotspots, CPU Profiling & Memory Allocation Thread Analysis 6.3 Database Service Diagnostics, Slow Queries & Exception Analysis
7 Chapter 7: Davis AI Engine, Baselining & Causation
7.1 Davis Deterministic Causation Engine vs. Pure Correlation 7.2 Automated Dynamic Baselining, Percentiles & Traffic Seasonality 7.3 Event Ingestion, Event Types & Event Hierarchy in Problem Evolution
8 Chapter 8: Problem Lifecycle, Root Cause Analysis & Alerting
8.1 Problem Lifecycle, Severity Categories & Root Cause Cards 8.2 Alerting Profiles, Delay Filters & Management Zone Routing 8.3 Problem Notification Integrations: Webhooks, Slack, ServiceNow & ITSM
9 Chapter 9: Digital Experience Monitoring: Synthetic Monitoring
9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths 9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault 9.3 Outage Detection, Performance Baselining & Maintenance Suppression
10 Chapter 10: Digital Experience Monitoring: Real User Monitoring (RUM)
10.1 RUM Architecture, OneAgent Script Injection & Mobile/OpenKit Telemetry 10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index 10.3 Apdex Performance Ratings, User Sessions & Session Replay Masking
11 Chapter 11: Log Management and Analytics on Grail with DQL
11.1 Log Management on Grail: Storage, Ingestion Pipelines & Log Masking 11.2 Dynatrace Query Language (DQL): Fetch, Filter, Fields & String Operations 11.3 DQL Aggregations: Summarize, MakeTimeseries, Sorting & Visualizations
12 Chapter 12: Platform Governance, OpenTelemetry & Automation
12.1 Management Zones: Scoping Observability, Dashboards & Access Control 12.2 Tagging Strategies: Automated Rule-Based Tags, Manual Tags & AWS/K8s Metadata 12.3 OpenTelemetry Ingestion, OpenPipeline & Dynatrace Workflows Automation
13 Chapter 13: Cloud Integrations & Agentless Infrastructure Ingestion
13.1 AWS, Azure & Google Cloud Integrations 13.2 VMware vSphere, Extensions & Other Agentless Ingestion Paths
14 Chapter 14: Business Analytics & Business Events
14.1 Business Events: Capture, Ingestion & the bizevents Grail Table 14.2 Business Analytics: Connecting Performance to Revenue, Conversion & KPIs
15 Chapter 15: Notebooks, Dashboards & Data Visualization
15.1 Notebooks: Section-Based Investigation & Shareable Analysis 15.2 Dashboards: Tiles, Variables, Segments & Continuous Monitoring 15.3 Choosing Visualizations: Data Explorer, Chart Types & Metric Selection
16 Chapter 16: Reporting, Metrics & User Behavior Analysis
16.1 Metrics on Grail: Built-in Metrics, Granularity & Retention 16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs 16.3 User Behavior Analysis: Bounce Rate, Landing & Exit Pages, Conversion Goals 16.4 Session Segmentation, User Journeys & Funnel Drop-Off Analysis
17 Chapter 17: Security, Vulnerability Analytics & Application Protection
17.1 Platform Security: Data Privacy, Encryption & Access Control 17.2 Third-Party Vulnerabilities, the Davis Security Score & Security Advisor 17.3 Code-Level Vulnerabilities, Attacks & Runtime Application Protection 17.4 Security Investigator, Notifications & the Remediation Workflow
16.2 Dashboard Reports, Subscriptions & Exporting Data via APIs
Key Takeaways Explain This Topic AI
Dashboard report subscriptions run weekly (every Monday) or monthly (first Monday), and the email carries a public link to the report rather than the report contents.
The Dashboards API and the Document API allow dashboards and notebooks to be created, exported, and version-controlled programmatically.
Modern Dynatrace platform APIs authenticate with an OAuth client or a platform token, not with a legacy environment API token.
The Grail DQL Query API lets external systems run DQL queries and consume the results, which is the supported route for feeding a data warehouse or BI tool.
Dashboards-as-code through the API is what keeps dashboard definitions reviewable, reproducible across environments, and recoverable after accidental edits.
Last updated: September 2026
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:
- Property Behaviour
- Weekly schedule Delivered every Monday morning
- Monthly schedule Delivered on the first Monday morning of the month
Generation Generated after the midnight preceding that Monday, in the tenant's timezone ; the email follows within the next six hours
Email contents A public link to the report — not the report contents. The link carries the timeframe matching the schedule: last week, or last month
Credentials The link opens without Dynatrace credentials , which is why report emails can be forwarded outside the tenant
Default state Reports are disabled by default per dashboard; someone with edit permission must turn on Enable reports before anyone can subscribe
- External recipients Any valid email address, including non-users, can be subscribed through the Reports API
- Opt-out Every report email carries an unsubscribe link
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
API What it is for
Dashboards API Create, read, update, and delete Dashboards Classic definitions, plus their sharing configuration
- Document API Manage latest-Dynatrace dashboards and notebooks as documents — export, import, version
- Grail DQL Query API Execute DQL queries and retrieve the records they return
- Metric ingest / Log ingest / Events / Business events APIs Push data in (Chapter 13)
- Settings API Manage configuration such as capture rules and monitoring settings as code
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.
- OAuth client Platform token
- Created by An administrator Any user, for themselves or a service user
Permissions Scopes defined by the administrator at creation The user's or service user's own permissions, narrowable to specific environments
- Lifetime Client credentials exchanged for short-lived bearer tokens Long-lived; expiry configurable, or never
- Limits — At most 10 per user per account ; bound to one account
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:
Export the dashboard definition.
Commit it to the repository alongside the service it monitors.
Review changes through the normal pull-request process.
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:
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 .
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 .