Dynatrace Synthetic Monitoring: Browser, HTTP, and Clickpath Monitors

Synthetic monitoring answers a question that APM can't: is your application working right now, even when no real user is touching it? Dynatrace Synthetic continuously runs scripted tests from locations around the world, catching outages and regressions before they impact users. This guide covers the full setup — from simple HTTP checks to multi-step clickpath monitors — and explains how to build an alerting strategy that wakes you up for the right reasons.

What Dynatrace Synthetic Monitoring Covers

Dynatrace offers three monitor types:

All three run from managed locations (Dynatrace's global network) or private locations (your own infrastructure, for testing internal apps).

Setting Up an HTTP Monitor

HTTP monitors are the fastest way to establish a baseline: is your endpoint up, and is it responding within SLA?

Creating an HTTP monitor

1. Go to Synthetic > Create a synthetic monitor > Create HTTP monitor
2. Set the URL, method, and request headers
3. Add response validation rules:
   • Status code: e.g., must equal 200
   • Response body: must contain "status":"ok"
   • Response time: must be under 2000ms
4. Choose locations and frequency (minimum 1 minute for HTTP)

Example validation for a health endpoint:

URL: https://api.yourapp.com/health
Method: GET
Headers:
  Authorization: Bearer {{secret.api_token}}
Validation:
  - Response code = 200
  - Response body contains: "healthy":true
  - Response time < 500ms

Dynatrace supports request templates with dynamic values — use {{SECRET_NAME}} syntax to inject credentials stored in Dynatrace's credential vault, so you're not hardcoding tokens in monitor configs.

Chaining HTTP requests

For API sequences (e.g., authenticate then call a protected endpoint), use a multi-step HTTP monitor:

1. Step 1: POST /auth/login → extract JWT from response body using JSONPath $.token
2. Step 2: GET /api/orders with Authorization: Bearer {{step1.token}}

This lets you test authenticated endpoints without embedding live credentials.

Setting Up a Browser Monitor

Browser monitors use a headless Chrome instance to load your page and capture everything: resource timings, Core Web Vitals, JavaScript errors, and a waterfall chart.

Creating a browser monitor

1. Synthetic > Create a synthetic monitor > Create browser monitor
2. Enter the URL and select Simple browser monitor (single URL) or Advanced configuration (multi-step)
3. Choose locations — select at least 3 regions for meaningful availability data
4. Set frequency: 5 minutes is a reasonable default for production

What browser monitors measure

Each run captures:

• Visually complete time — when the page stops rendering
• Speed Index — how quickly content appears visually
• Largest Contentful Paint (LCP) — Core Web Vitals
• Cumulative Layout Shift (CLS)
• First Input Delay (FID)
• Resource waterfall — every asset, its size, and load time
• JavaScript errors — caught during page load

The waterfall view is particularly useful for identifying third-party scripts that are blocking render or assets being loaded from slow CDN nodes in specific regions.

Clickpath Monitors: Testing User Flows

Clickpath monitors are the most powerful synthetic option. They simulate a real user navigating through your application: search for a product, add it to cart, proceed to checkout.

Recording a clickpath

Use the Dynatrace Recorder (a Chrome extension) to record your steps:

1. Install the Dynatrace Recorder extension
2. Navigate to the page you want to test
3. Click Record
4. Perform the user actions: click buttons, fill forms, navigate pages
5. Stop recording and export the script to Dynatrace

The recorder generates a JSON-based script. You can edit it manually for fine-grained control.

Clickpath script structure

A clickpath consists of steps, each with:

{
  "steps": [
    {
      "type": "navigate",
      "url": "https://yourapp.com/login",
      "description": "Go to login page"
    },
    {
      "type": "click",
      "target": {
        "locator": {
          "type": "css",
          "value": "#email-input"
        }
      },
      "description": "Click email field"
    },
    {
      "type": "type",
      "value": "test@example.com",
      "description": "Enter email"
    },
    {
      "type": "click",
      "target": {
        "locator": {
          "type": "css",
          "value": "button[type=submit]"
        }
      },
      "description": "Submit login form"
    },
    {
      "type": "waitForElement",
      "target": {
        "locator": {
          "type": "css",
          "value": ".dashboard-header"
        }
      },
      "timeout": 5000,
      "description": "Wait for dashboard to load"
    }
  ]
}

Validating clickpath steps

Each step can have a validation:

• Element exists: confirm a DOM element is present
• Element contains text: e.g., confirm "Welcome, Jane" appears after login
• URL matches: confirm navigation landed on the right page
• JavaScript expression: custom assertions via return document.title === "Dashboard"

Performance metrics per step

Each step gets individual timing data. You can set per-step performance thresholds and get alerted if, for example, the checkout page takes more than 3 seconds to load — even if the overall flow succeeds.

Private Synthetic Locations

Public locations cover external availability from Dynatrace's network. For testing internal apps — staging environments, VPN-protected services, APIs behind a firewall — you need a private location.

Installing a private ActiveGate

Private locations run via an ActiveGate — a lightweight proxy node that executes synthetic monitors from inside your network:

wget -O Dynatrace-ActiveGate.sh \
  "https://<env>.live.dynatrace.com/api/v1/deployment/installer/gateway/unix/default/latest" \
  --header="Authorization: Api-Token <token>"

chmod +x Dynatrace-ActiveGate.sh
sudo ./Dynatrace-ActiveGate.sh --enable-synthetic

Register the location: Synthetic > Private locations > Add location — assign the ActiveGate.

Now you can run monitors against https://internal.staging.yourapp.com from inside your network. This is essential for staging environment validation.

Global Locations and Availability Strategy

Dynatrace operates public synthetic nodes in 15+ countries. Choosing the right locations depends on where your users are:

• US East, US West — minimum for any US-focused app
• EU West (Frankfurt, London) — GDPR-relevant; latency often differs significantly from US
• APAC (Tokyo, Singapore, Sydney) — if you have users in Asia Pacific
• São Paulo — often overlooked; Latin American latency can be 3-5× US

Run from at least 3 locations. This gives you:

• Majority-vote availability (1-of-3 failure = possible fluke; 2-of-3 = real outage)
• Regional latency comparison (is slowness global or isolated to EU?)

Alerting Configuration

Default synthetic alerts fire when a monitor fails from any single location. This creates noise — transient network blips trigger pages. Tune it:

Alert sensitivity

Under Monitor > Edit > Alerting:

• Outage handling: Alert only if N consecutive failures occur from the same location (set to 2-3)
• Performance degradation: Alert when performance drops below X% of the baseline for Y consecutive runs
• Across locations: Require failures from multiple locations before opening a Problem

Linking synthetic to Problems

Dynatrace correlates synthetic failures with infrastructure events via Davis AI. If your browser monitor starts failing at the same time a deployment event lands or a host spikes on CPU, Davis surfaces that correlation in the Problem card automatically.

Notification routing

Route synthetic Problems to the right team:

• PagerDuty: native integration, severity mapping from Dynatrace problem severity
• Slack: webhook-based; include monitor name, step that failed, and screenshot URL in the message
• Email: fine for non-critical monitors; too slow for P1 outages
• ServiceNow / Jira: auto-create incidents

Synthetic Monitoring vs End-to-End Testing

Synthetic monitoring is continuous — it runs 24/7 from production. End-to-end testing is event-driven — it runs against a specific build before deployment.

Both matter, and they serve different purposes:

Dynatrace Synthetic excels at the continuous monitoring side. For the pre-deploy gate — running full user journey tests against your staging branch before you push to production — you need a dedicated E2E testing layer. HelpMeTest is built for exactly this: write your user flows in plain English, run them as a CI check, and catch regressions before they reach production. Dynatrace then monitors what ships.

Used together: HelpMeTest blocks broken deploys, Dynatrace catches anything that slips through and monitors production health around the clock.

Reporting and SLAs

Synthetic data feeds into Dynatrace's Service Level Objectives. Create an SLO tied to your synthetic monitor:

• Availability SLO: e.g., 99.9% of monitor runs must succeed (rolling 30 days)
• Performance SLO: e.g., 95th percentile step time under 3 seconds

SLOs generate burn rate alerts — instead of a page for every failed run, you get alerted when you're consuming your error budget faster than planned.

The Synthetic availability report (under Reports) gives a daily/weekly/monthly breakdown of availability percentage per monitor and per location — useful for SLA reporting to stakeholders.

Common Pitfalls

Login forms with CAPTCHA: Synthetic monitors can't solve CAPTCHAs. Use IP allowlisting or a test-bypass mechanism for the synthetic user account.

Dynamic element locators: If your app generates IDs like button-123abc dynamically, CSS locators break. Use data-testid attributes in your application code for stable locators:

<button data-testid="checkout-submit">Place Order</button>

Then target [data-testid="checkout-submit"] in your clickpath — stable across builds.

Session cookies: If your clickpath tests hit rate limits or CAPTCHA after multiple runs, the synthetic user's session is being flagged. Rotate synthetic user credentials periodically and ensure your WAF has an allowlist for the Dynatrace synthetic IP ranges (published in the Dynatrace documentation).

Not validating business outcomes: A clickpath that just clicks through without validating outcomes is a reachability test, not a functional test. Always add validations that confirm the correct data appears — order confirmation number, success message, updated cart count.

Getting the Most Out of Synthetic

Start with HTTP monitors on your critical endpoints — health checks, key APIs. Add a browser monitor on your homepage and any page that runs expensive JavaScript. Then build clickpaths for your top 2-3 user journeys: login, core workflow, checkout.

Set up private locations early if you have staging environments. The ability to run synthetic tests against internal environments is one of Dynatrace's most underused features — it effectively gives you continuous pre-production monitoring at no extra infrastructure cost.

Synthetic monitoring is not a replacement for comprehensive testing, but it is an always-on safety net. When something breaks at 3am on a Sunday, synthetic monitoring is the system that pages you — not a user.