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
Alert Source Webhooks	Receive Davis problem OPEN and RESOLVED notifications via webhook

How Authentication Works

Dynatrace exposes two API planes. Only the API token is required; the OAuth client is optional and adds the Grail data types (logs, metrics, traces, business events, change events, user sessions):

Credential	Required?	Used for	Why
API token	Required	Problems, entities, alerting rules (Environment API v2) + alert webhooks	Works on every tenant, including Dynatrace Managed
OAuth client (client id + secret + account URN)	Optional	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. Skip it on Managed / non-Grail tenants.

note

Grail queries (logs, metrics, traces, business events, change events, user sessions) are available on Dynatrace SaaS environments. On Dynatrace Managed or non-Grail tenants you can leave the OAuth fields blank — problems, entities, alerting rules, and alert webhooks work with the API token alone, but the Grail data types will be unavailable (the integration targets Grail SaaS for those signals).

Prerequisites

• A Dynatrace environment (SaaS / Grail recommended for log, metric, trace, business-event, and session queries)
• Permission to create an API access token and an OAuth client in your Dynatrace account
• 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 classic SaaS / Managed 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 (optional — for Grail queries)

Skip this step on Dynatrace Managed / non-Grail tenants; the integration still works (problems, entities, alerting rules, webhooks) without it — you just won't have the Grail data types (logs/metrics/traces/business-events/change-events/sessions).

1. In Account Management (account.dynatrace.com) → Identity & access management → OAuth clients
2. Create a new client and assign storage:buckets:read plus the read scope for each data type you want (each tool requests only its own scope, so grant just what you need):
   • storage:logs:read (logs)
   • storage:metrics:read (metrics)
   • storage:spans:read (distributed traces)
   • storage:bizevents:read (business events)
   • storage:events:read (change events — deployments, config changes)
   • storage:user.sessions:read (RUM user sessions)
   • slo:slos:read (service-level objectives — this one does not need storage:buckets:read)
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 (optional): the dt0s02. client id from step 2
• OAuth Client Secret (optional): the client secret from step 2
• OAuth Account URN (optional): urn:dtaccount:<account-uuid>

Leave the three OAuth fields blank if you don't need log/metric queries (e.g. on Managed).

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

Each Grail tool requests only its own scope, so grant just the data types you intend to use; an ungranted scope only disables its matching tool (not the rest).

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 classic/Managed) → 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 with all eight scopes:

storage:buckets:read
storage:logs:read
storage:metrics:read
storage:spans:read
storage:bizevents:read
storage:events:read
storage:user.sessions: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). Grail (and therefore the OAuth client) is available on Dynatrace SaaS only; on Dynatrace Managed the OAuth client has no effect and the storage scopes don't apply.

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 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

• Logs, metrics, traces, business events, change events, user sessions, and service-level objectives are read from Grail and require the OAuth client. They are unavailable on Dynatrace Managed / non-Grail environments (problems, entities, alerting rules, and alert webhooks still work there via the API token).
• 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 (Dynatrace Managed / older SaaS):

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>
• Verify the OAuth client grants at least storage:buckets:read (the credential check mints a token for it; required by every Grail storage query)
• 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