Linking Dynatrace as a source

Connect your Dynatrace environment to sync problems, events, entity inventory (hosts, services, applications, process groups), audit logs, vulnerabilities, metric metadata, and SLOs into the PostHog data warehouse. This is useful for reporting on incident history, availability, and infrastructure alongside your product data.

Prerequisites

• A Dynatrace SaaS or Managed environment and its environment URL. For SaaS this looks like https://abc12345.live.dynatrace.com; for Managed it's https://your-domain/e/your-environment-id.
• Permission to create access tokens in that environment.

Adding a data source

1. In PostHog, go to the Sources tab of the data pipeline section.
2. Click + New source and click Link next to this source.
3. Enter your credentials (see Configuration below) and click Next.
4. Select the tables you want to sync, choose a sync method and frequency, then click Import.

Once the syncs are complete, you can start querying this data in PostHog.

When linking Dynatrace, you need two values:

• Environment URL - the URL where you open Dynatrace, for example https://abc12345.live.dynatrace.com.

• API access token - create one under Settings > Access tokens in Dynatrace. Grant read scopes only for the data you want to sync:

  • problems.read for problems
  • events.read for events
  • entities.read for hosts, services, applications, and process groups
  • auditLogs.read for audit logs (audit logging must be enabled in the environment)
  • securityProblems.read for vulnerabilities
  • metrics.read for metric metadata
  • slo.read for SLOs

Tables the token can't read are flagged in the table picker, so you can deselect them instead of granting every scope.

Sync modes

Each table can be synced in one of several modes, depending on what the source supports:

• Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
• Incremental – only new or updated rows are synced on each run, using a cursor field (such as an updated_at timestamp). Cheaper than a full refresh, but deletes aren't captured.
• Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
• Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.

See sync methods for a full explanation of how each mode works and how to choose between them.

Problems, events, and audit logs support incremental syncs based on their timestamps. The other tables are snapshots of the current state, so they use full refresh.

Available tables

Incremental tables sync only new or updated records on each run. Full refresh tables reload all data on each sync.

Sync limitations

• On the initial sync, problems go back 365 days, and events and audit logs go back 30 days (bounded by your environment's retention).
• The entity tables (hosts, services, applications, process groups) include entities active in the last 30 days.
• Metric time series aren't synced — the metrics table contains metric metadata (the metric catalog), not data points.

Troubleshooting

• Invalid Dynatrace API token - the token was rejected. Check that it hasn't expired or been revoked, and that the environment URL points at the environment the token was created in.
• Missing scope errors - grant the read scope listed in the prerequisites for the affected table, or deselect the table.

If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.

Configuration

Supported tables