Dynatrace Integration

Connect Dynatrace to enable the AI agent to investigate incidents using Davis problems, metrics, logs, distributed traces, business events, RUM user sessions, monitored entities (Smartscape topology), and change events. You can also forward Dynatrace Davis problems to Autoheal via a problem-notification webhook so they are ingested, grouped, and available for triage on the Alerts page.

Capabilities

Once connected, the AI agent can:

Capability	Description
List/Get Problems	Review Davis-correlated problems, their root cause, impact, and affected entities
Query Metrics	Query metrics from Grail using DQL (timeseries)
Query Logs	Query logs on Grail using DQL (fetch logs)
Query Traces	Query distributed traces / spans on Grail (fetch spans) to follow latency and errors across services
Query Business Events	Query business events on Grail (fetch bizevents) to correlate system health with business-transaction volume
Query User Sessions	Query RUM user sessions on Grail (fetch user.sessions) to find the customers/sessions impacted by an incident
List Entities	Navigate Smartscape topology — hosts, services, applications, Kubernetes clusters, and more
Query Events	Query change events on Grail (fetch events) — deployments, configuration changes, availability, custom events — the "what changed" timeline (distinct from Davis problems)
List Alerting Rules	Read the configured alerting-rule catalog — classic metric events and Grail DQL custom alerts (Davis anomaly detectors) — for alert-definition sync
List SLOs	Read service-level objectives — targets, warning thresholds, timeframes — from the Grail-native SLO Service API
Query Grail (generic)	Run read-only DQL for Grail data types without a dedicated tool — security events, RUM user events/replays, entities, Smartscape topology, system events
Alert Source Webhooks	Receive Davis problem OPEN and RESOLVED notifications via webhook

How Authentication Works

Dynatrace exposes two API planes, and both are required. The API token covers Davis problems, entities, and alerting rules; the OAuth client covers all Grail data (logs, metrics, traces, business events, change events, user sessions, SLOs). Because log/metric/trace access is the core of the integration and is only reachable through Grail, the OAuth client is mandatory:

Credential	Required?	Used for	Why
API token	Required	Problems, entities, alerting rules (Environment API v2) + alert webhooks	The Environment API plane
OAuth client (client id + secret + account URN)	Required	Logs, metrics, traces, business events, change events, user sessions (Grail DQL Query API) + service-level objectives (SLO Service API)	Grail data requires an OAuth bearer token; the classic metrics.read / events.read / slo.read token scopes cannot be granted on Grail tenants. Needs a Grail-enabled SaaS environment.

note

This integration requires a Grail-enabled Dynatrace SaaS environment and both credentials — the API token and the OAuth client. Fetching logs, metrics, and traces is the core of the integration and is only possible through Grail via the OAuth client, so OAuth is mandatory. Dynatrace Managed / non-Grail tenants are not supported (they have no Grail/OAuth plane).

Prerequisites

• A Grail-enabled Dynatrace SaaS environment (Dynatrace Managed / non-Grail is not supported)
• Permission to create both an API access token and an OAuth client in your Dynatrace account (both are required)
• Your Dynatrace account URN (urn:dtaccount:<account-uuid>)

Setup

1

Create an API Access Token

1. In Dynatrace, open the Access Tokens page — on Grail-native tenants press Cmd/Ctrl + K and search "Access Tokens"; on an older/classic SaaS UI it's under Settings → Access tokens — then click Generate new token
2. Name it (e.g., "Autoheal")
3. Select these scopes:
   • problems.read (Read problems)
   • entities.read (Read entities)
   • settings.read (Read settings — for metric events)
4. Generate and copy the token (starts with dt0c01.)

2

Create an OAuth Client (required — for Grail data)

Required. Grail (logs/metrics/traces/business-events/change-events/sessions/SLOs) is only reachable through this OAuth client, so the integration can't be saved without it. Requires a Grail-enabled SaaS environment.

1. In Account Management (account.dynatrace.com) → Identity & access management → OAuth clients
2. Create a new client and grant it Dynatrace's read-only scope set — the full recommended list is in For full functionality below. Autoheal mints the token without listing scopes, so it uses exactly what you grant: grant the full set to enable every tool, or a subset (e.g. storage:buckets:read + storage:logs:read for logs, slo:slos:read for SLOs) if you prefer least privilege.
3. Copy the client ID (starts with dt0s02.) and client secret (shown only once)
4. Note your account URN — urn:dtaccount:<account-uuid> (found in Account Management)

3

Add the Integration in Autoheal

1. Go to Integrations in Autoheal and click Dynatrace
2. Enter a name (e.g., "Production Dynatrace")

4

Configure Credentials

Enter the following:

• Environment URL (required): e.g. https://abc12345.live.dynatrace.com
• API Token (required): the dt0c01. token from step 1
• OAuth Client ID (required): the dt0s02. client id from step 2
• OAuth Client Secret (required): the client secret from step 2
• OAuth Account URN (required): urn:dtaccount:<account-uuid>

All five fields are required — the integration needs both the Environment API (token) and Grail (OAuth) planes.

5

Test and Save

Click Test Connection, then Save. The check reports the Environment API (token) and Grail (OAuth) planes separately. It fails only on a problem that breaks a whole plane — an Environment API scope error, or OAuth credentials that are incomplete or can't obtain a token. Individual Grail scopes you didn't grant are shown as UNAVAILABLE (that tool is simply disabled), not as a failure — so granting only the tables you need still passes.

Required Scopes

Credential	Scope	Why It's Needed
API token	problems.read	List and read Davis problems
API token	entities.read	List monitored entities (Smartscape)
API token	settings.read	Read metric-event alerting rules
OAuth client	storage:buckets:read	Access the Grail buckets backing every Grail query (required for all of the below)
OAuth client	storage:logs:read	Read logs from Grail (fetch logs)
OAuth client	storage:metrics:read	Read metrics from Grail (DQL timeseries)
OAuth client	storage:spans:read	Read distributed traces from Grail (fetch spans)
OAuth client	storage:bizevents:read	Read business events from Grail (fetch bizevents)
OAuth client	storage:events:read	Read change events from Grail (fetch events)
OAuth client	storage:user.sessions:read	Read RUM user sessions from Grail (fetch user.sessions)
OAuth client	slo:slos:read	Read service-level objectives from the Grail-native SLO Service API (GET /platform/slo/v1/slos) — does not require storage:buckets:read

Autoheal mints one OAuth token without enumerating scopes, so it uses exactly what the client was granted: granting a scope enables its tool, and an ungranted one only disables its matching tool (not the rest). Grant the full read-only set below to enable everything.

For full functionality (all tools)

To enable every capability, grant the complete set below. The two credentials are created independently in Dynatrace, then entered together in Autoheal.

1. API access token — open the Access Tokens page (Cmd/Ctrl + K → "Access Tokens", or Settings → Access tokens on an older/classic SaaS UI) → Generate new token with all three scopes:

problems.read
entities.read
settings.read

2. OAuth client — Account Management (account.dynatrace.com) → Identity & access management → OAuth clients → create a client and grant Dynatrace's read-only scope set below. It covers every current tool plus forward-compatibility as new tools ship; Autoheal mints the token without listing scopes, so it uses whatever you grant (a subset works too):

storage:logs:read
storage:events:read
storage:metrics:read
storage:bizevents:read
storage:system:read
storage:buckets:read
storage:bucket-definitions:read
storage:spans:read
storage:entities:read
storage:smartscape:read
storage:fieldsets:read
storage:user.events:read
storage:user.sessions:read
storage:user.replays:read
storage:security.events:read
storage:files:read
openpipeline:configurations:read
storage:filter-segments:read
automation:workflows:read
automation:rules:read
automation:calendars:read
extensions:definitions:read
extensions:configurations:read
document:documents:read
document:environment-shares:read
document:direct-shares:read
settings:objects:read
settings:schemas:read
slo:slos:read

note

storage:buckets:read is mandatory — every Grail storage query needs it. slo:slos:read is the only scope that does not require it (SLOs use the SLO Service API, not Grail storage). The OAuth client requires a Grail-enabled Dynatrace SaaS environment; Dynatrace Managed / non-Grail tenants have no Grail plane and are not supported.

3. Enter both credentials in Autoheal (Integrations → Dynatrace):

Autoheal field	Value	Needed for
Environment URL	https://<env-id>.live.dynatrace.com	everything
API Token	the dt0c01.… token	problems, entities, alerting rules, webhooks
OAuth Client ID	the dt0s02.… client id	all Grail tools
OAuth Client Secret	the client secret (shown once at creation)	all Grail tools
OAuth Account URN	urn:dtaccount:<account-uuid>	all Grail tools

Then click Test Connection — with the full set granted, every line reports OK — and Save.

Example Queries

Once connected, you can ask the AI agent:

What Dynatrace problems are open for the checkout service?

Show me CPU usage for the web hosts over the last hour

Search Dynatrace logs for errors on the payment service in the last 30 minutes

Show Dynatrace security events for the payment service in the last hour

Show the slowest checkout-service traces in the last hour

Which customers had frustrated sessions during the outage?

What deployments or config changes happened right before this problem started?

Which service-level objectives are defined and what are their targets?

Limitations

• Requires a Grail-enabled Dynatrace SaaS environment. The core data — logs, metrics, traces, business events, change events, user sessions, and SLOs — is read from Grail via the OAuth client, which is mandatory. Dynatrace Managed / non-Grail tenants are not supported (no Grail/OAuth plane).
• SLOs use the Grail-native SLO Service API (GET /platform/slo/v1/slos, scope slo:slos:read), not the classic /api/v2/slo endpoint (whose slo.read token scope isn't grantable on Grail tenants). On Grail, SLO read access therefore comes from the OAuth client, not the API token.

Alert Source Setup

Dynatrace can also act as an alert source by forwarding Davis problems to Autoheal via a problem-notification webhook.

1

Enable the Webhook in Autoheal

1. Open your Dynatrace integration in Autoheal
2. Scroll to the Alert Source section
3. Enable the webhook and copy the Webhook URL
4. Optionally, enter a Webhook Signing Secret for additional authentication

2

Forward problems to the webhook

Dynatrace has two ways to forward problems — use whichever your tenant supports.

Option A — Workflows (newer Grail tenants; the classic Problem notifications page is unavailable there):

1. Open the Workflows app (Cmd+K → "Workflows").
2. Create a workflow with a Problem trigger (fires when a Davis problem opens, and optionally on close).
3. Add a Send HTTP request action — method POST, URL = the Webhook URL.
4. Set the request body to the JSON below, mapping each value from the workflow's problem record. Use the action's "test with a sample problem" to confirm the field expressions for your tenant.
5. If you set a Webhook Signing Secret, add an Authorization: Bearer <your secret> header.

Option B — Problem notifications (older SaaS, where the classic Problem notifications page is available):

1. Go to Settings → Integration → Problem notifications → Add notification → Custom integration.
2. Name it (e.g., "Autoheal") and paste the Webhook URL.
3. Put the JSON below in the Custom payload field.
4. If you set a Webhook Signing Secret, add an Additional HTTP header Authorization: Bearer <your secret>.
5. Select an alerting profile (default forwards all), Send test notification, then Save changes.

Expected payload (both options):

{
  "problemId": "{ProblemID}",
  "pid": "{PID}",
  "state": "{State}",
  "title": "{ProblemTitle}",
  "severity": "{ProblemSeverity}",
  "impact": "{ProblemImpact}",
  "url": "{ProblemURL}",
  "tags": "{Tags}",
  "impactedEntityNames": "{ImpactedEntityNames}",
  "details": "{ProblemDetailsText}"
}

Option B uses these {...} placeholders directly. For Option A, replace each value with the equivalent Workflow expression pulled from the problem record.

3

Verify

Trigger or wait for a problem to verify it appears on Autoheal's Alerts page. Dynatrace sends both problem-open and problem-resolved events to the same endpoint.

note

The Webhook Signing Secret is an optional second layer of authentication. The webhook URL already contains a unique secret identifying your integration; the signing secret adds verification via the Authorization header.

Troubleshooting

Test Connection: Environment API failed (401/403)

• Verify the API token is correct and not expired
• Ensure the token has the problems.read, entities.read, and settings.read scopes
• Confirm the Environment URL is correct (e.g. https://abc12345.live.dynatrace.com)

Test Connection: Grail (OAuth) failed

Test Connection only fails the Grail plane when the credentials themselves are wrong — not when an individual table scope is missing.

• Ensure the OAuth client id, secret, and account URN are all entered (a partially-filled set fails)
• Confirm the account URN is in the form urn:dtaccount:<account-uuid>
• The credential check mints a token without requesting specific scopes, so a failure here means the client id/secret/account URN are wrong (Dynatrace SSO returns 400/invalid_client), not a missing data scope
• Grail queries require a Grail-enabled SaaS environment (not Dynatrace Managed)
• A specific capability shown as UNAVAILABLE (e.g. metrics) just means that scope wasn't granted — add the scope for that table if you want the tool, or ignore it

Metric query returns NOT_AUTHORIZED_FOR_TABLE

• The OAuth client (and the token's subject user) needs storage:metrics:read to read the Grail metrics table — add it alongside the logs/buckets scopes
• Use Grail-native metric keys (e.g. dt.host.cpu.usage); classic builtin: keys may not resolve via DQL

Webhook Alerts Not Appearing in Autoheal

• Verify the webhook URL in Dynatrace matches the URL shown in Autoheal
• Ensure the custom payload matches the template shown in the Alert Source section
• Check the alerting profile selected on the notification forwards the relevant problems
• Verify the webhook is enabled in the Autoheal integration settings

Webhook Returns 401 Unauthorized

• If you configured a Webhook Signing Secret in Autoheal, ensure the Dynatrace notification has an Authorization header with value Bearer <same secret>
• If you don't want header verification, remove the Webhook Signing Secret from the Alert Source section in Autoheal