Replace third-party Synthetic integrations
- Latest Dynatrace
- How-to guide
- 4-min read
What changes
The Classic third-party Synthetic API is being retired. All third-party monitors that are still active or needed must be migrated to a supported ingestion path. There are two replacement paths depending on the type of check. See Determine the replacement path.
Identify third-party monitors
Go to 
Synthetic Classic. In the left sidebar, use the Type of synthetic monitor filter to select the third-party monitor types. The Status filter shows which monitors are Active and which are Inactive.
Determine the replacement path
For each active third-party monitor, identify the check type and select the appropriate path.
Path A: Network-level checks (ping, TCP, DNS)
Use a native network availability monitor (NAM) only when it can reproduce the existing check. Before choosing this path, record and compare:
- Protocol and target type.
- Execution locations and network reachability.
- Execution frequency.
- Timeout, retry, port, DNS, and success criteria.
- Required per-target result detail.
- Alert thresholds and outage behavior.
Choose NAM when all required behaviors are supported. Create the replacement monitor, run it in parallel with the existing integration, and compare targets, availability, duration, and alert results for the agreed observation period. Retire the existing integration only after the comparison passes.
Path B: Tests without a direct native equivalent
For browser transactions, API or protocol checks, mobile or desktop application tests, load tests, vendor-hosted tests, and other checks without a direct native equivalent in Dynatrace Synthetic, use the dynatrace-external-tests starter pack as the replacement ingestion pattern.
The starter pack is a Monaco bundle that provides the components needed to ingest results from an external runner into your environment on latest Dynatrace:
- A dedicated ingest endpoint (
/platform/ingest/custom/events/external.tests) that accepts JSON events from external runners such as Playwright, Selenium, k6, CI jobs, or third-party synthetic platforms. - Automated processing that extracts availability, duration, failure, and step metrics; masks credentials in URLs; and makes results queryable in Grail. Results appear in the Smartscape topology alongside the applications they test.
- Anomaly detection for local outages, global outages, performance anomalies, and error-code spikes. Resulting problems can use the environment's existing notification profiles.
- Two dashboards: Overview and Usage.
This path requires an existing test runner or external testing product, a mapping from its results to the external-test event schema, Monaco CLI, deployment and ingest tokens, and the required Dynatrace permissions.
See Getting started with dynatrace-external-tests for deployment instructions and the external-test data model.
Verify the replacement
For every active third-party integration, confirm that:
- The replacement covers the original targets, locations, frequency, and success criteria.
- Replacement events, metrics, topology, dashboards, and alerts are available.
- Old and new results have been compared for the agreed observation period.
- The integration no longer depends only on the Classic ingestion endpoint.
Retire the previous integration only after the replacement passes these checks.