The Dynatrace alternative that runs real Playwright
Dynatrace browser monitors are recorded clickpaths on its own engine, so the Playwright suite your team already maintains cannot come with you. A Checkly browser check is that spec file: same code in your IDE, in CI, and in production.
Playwright-native Runs locally No per-step billing
Trusted to monitor mission-critical flows at teams like these
“The ease of integration in our pipeline was remarkable. We have everything defined in a CI/CD pipeline using GitHub Actions using the CLI.”
Everything scaffolds out based on a configuration, so we just update a configuration file which specifies the environments, what services are there, what the URLs are, and from that, we just generate all the groups and their checks.
Built for the way engineers already write tests
Checkly is built on open source, so your monitoring is not trapped in one vendor's format. The checks are ordinary TypeScript and ordinary Playwright, versioned like the rest of your stack.
Your Playwright suite is the monitor
The file your team already wrote, already reviews, and already runs in CI becomes an always-on production check. Nothing is re-recorded, nothing is translated into a proprietary format, and there is no second copy of the journey to keep in sync.
Monitors change in pull requests
Checks are .check.ts files in the repository. The PR that changes the login flow changes the check that covers it, review catches the mistake, and git tells you who changed the alert threshold and when.
One product, not one tab
Every engineer here works on API, browser, and heartbeat monitoring. It is the whole roadmap, not a module competing for attention with APM, logs, security, and real user monitoring.
A clickpath is not a test suite
This is the difference that decides most evaluations, and it is not about features. It is about whether the artefact you already own can do the job, or whether you have to build a second one in a format only one vendor can read.
Is a Playwright spec file.
If your team already writes Playwright, day one is pointing a check at a file that exists.
Is a recorded clickpath.
There is no playwright.config.ts, no expect(), no page.route(), and no npm import. A Playwright suite cannot be carried across.
Checkly vs. Dynatrace
A code-first synthetic monitoring platform against the synthetic module inside a full-stack observability suite. Both rows they win are in the table too.
Native Playwright runtime
Local run and debug
Monitors defined in your repo
TypeScript authoring
npm packages and request mocking
Cross-browser checks
Heartbeat monitoring
Status pages
Network-layer monitors
Official Terraform provider
Full-stack APM correlation
How browser runs are billed
● Full support·○ Limited·✕ Not available
Where Dynatrace leads: a failed synthetic run links straight to the PurePath backend trace, the host metric, and the log in one platform, and Davis AI puts causal root-cause analysis on top of its topology graph. It also has real user monitoring with session replay, native on-call and incident workflows, a much larger public probe network than our 22 locations, and compliance coverage including SOC 2 Type II, ISO 27001, FedRAMP Moderate, and HIPAA. Checkly does none of that. If a single correlated platform is the requirement, Dynatrace is the right answer. If the requirement is that developers own the synthetics, keep reading.
Every step in the journey is a line item
Dynatrace bills browser monitors by the action, not by the run. That turns coverage into a budget conversation: the honest way to control the bill is to shorten the journey, so the steps that get cut are the ones deep in checkout where the real failures live.
Billed per run. Steps are free.
A thirty-step journey costs the same as a three-step one.
Billed per action inside the journey.
List rates read from dynatrace.com/pricing on 3 September 2026. The annual commitment they sit on top of is not published.
One monitor, one year
At the listed $4.50 per 1,000 browser actions, that single checkout monitor bills roughly $23,652 a year, before a second monitor, a sixth location, or a single CI-triggered run. Cut the journey to three steps and the bill falls by seventy percent, which is exactly why teams stop monitoring the end of checkout.
“Checkly has helped us save engineering resources and expenses.”
When we get an alert from Checkly, we can go directly to our customers and tell them about any issues. The number of our customer support tickets are then reduced because the customer is already proactively informed about problems without having to report the issues themselves.
From your IDE to production in three commands
Write the check, run it locally, deploy it. The same workflow as the rest of your code, with the same tools and the same review.
Write the check as a Playwright spec
The journey is a spec file in the repository, using the Playwright API your team already knows. If a version of it is already in your test suite, you are starting from something that works rather than from a recorder.
Point a check at it and run it locally
A construct turns that spec into a monitor: frequency, locations, alerting, all in code and all in the pull request. npx checkly test runs it on Checkly infrastructure from your machine or from CI, before anything reaches production.
Deploy it for 24/7 monitoring
One command versions and ships your monitoring alongside the application deploy, live across 22 public locations and any private locations you run. The next change to the flow arrives the same way: as a diff someone reviewed.
Fit check
When should you choose Checkly over Dynatrace?
Checkly is a strong fit when
- Your team already writes Playwright tests and wants to run those exact files as production monitors.
- You want monitors reviewed in a pull request, run locally, and deployed by CI instead of clicked together in a portal.
- You want the bill to track how often a journey runs, not how many steps that journey has.
Checkly may not be the best fit when
- You want one vendor for APM, logs, infrastructure metrics, real user monitoring, and synthetics in a single correlated platform.
- You need on-call scheduling and incident management inside the monitoring tool rather than in PagerDuty, Opsgenie, or Incident.io.
- You need probe coverage in markets outside the 22 public locations Checkly runs.
Key facts
Checkly at a glance
The facts a buyer usually has to dig for, in one place, each one traceable to the documentation it comes from.
- Browser checks
The real Playwright engine, not a recorder
A Checkly browser check is a Playwright spec file. The same script runs in VS Code, in npx checkly test, and in production. Dynatrace browser monitors are recorded clickpaths that run on its own Chromium engine, so there is no Playwright script to carry across.
Checkly Playwright check suite docs (opens in a new tab)Dynatrace synthetic monitoring docs (opens in a new tab)
- Where monitors live
TypeScript files in your repository
Checks are .check.ts files reviewed in the same pull request as the feature they cover, then shipped with npx checkly deploy. Nothing is authored in a console first.
Checkly monitoring as code docs (opens in a new tab)Checkly CLI docs (opens in a new tab)
- Infrastructure as code
Official Terraform and Pulumi providers
Checkly publishes an official Terraform provider on the HashiCorp registry alongside the TypeScript CLI, so Terraform shops get the same code-first workflow.
Checkly Terraform provider (opens in a new tab)Checkly monitoring as code docs (opens in a new tab)
- Locations
22 public locations, plus private locations
Public locations span the Americas, EMEA, and Asia Pacific. Private locations run a lightweight agent inside your own network for internal services.
- Non-HTTP coverage
ICMP, TCP, DNS, SSL, and heartbeat monitors
Checkly monitors network-layer endpoints as well as HTTP, and heartbeat monitors cover cron jobs and scheduled tasks, which Dynatrace has no native equivalent for.
- How runs are billed
Per check run, from one included pool
Browser, API, and heartbeat runs draw on the same plan allocation. Dynatrace bills browser monitors per action taken inside the journey, listed at $4.50 per 1,000 browser actions, on top of an annual commitment it does not publish.
Checkly pricing (opens in a new tab)Dynatrace pricing (opens in a new tab)
- Where Dynatrace leads
Full-stack correlation and Davis AI
OneAgent and PurePath connect a failed synthetic run to the backend trace, the host metric, and the log in one platform. Davis AI adds causal root-cause analysis on its topology graph, and real user monitoring with session replay sits next to it. Checkly does none of that.
Dynatrace synthetic monitoring docs (opens in a new tab)Dynatrace pricing (opens in a new tab)
Facts checked . Vendor pricing and feature pages change without notice, so verify anything decision-critical against the linked source.
Decision criteria
How to evaluate Checkly against Dynatrace
Six questions that decide this comparison for most teams. Each one links to the documentation where you can check both products yourself.
What the browser monitor actually executes
If the monitor is a recorded clickpath, the Playwright suite your team already maintains cannot be reused. You are maintaining a second, weaker copy of every critical journey.
How Checkly answers it: Checkly runs Playwright directly, including multi-file check suites, fixtures, and playwright.config.ts. The spec file is the monitor.
VerifyCheckly Playwright check suite docs (opens in a new tab)Dynatrace synthetic monitoring docs (opens in a new tab)
Whether a failing check can be reproduced locally
At 3am the useful question is not what the screenshot showed, it is what happens when you run the same steps yourself with DevTools open.
How Checkly answers it: npx checkly test runs any check from your machine or from CI on Checkly infrastructure before it ships, and the same script runs under plain Playwright locally.
VerifyCheckly CLI docs (opens in a new tab)Dynatrace synthetic monitoring docs (opens in a new tab)
Who owns a monitor after a release
A monitor edited in a console is invisible to code review, so a UI change and the check that covers it drift apart until the check goes stale or starts crying wolf.
How Checkly answers it: Monitors are TypeScript in the repository. The pull request that changes the flow changes the check, and CI blocks the deploy when it fails.
VerifyCheckly monitoring as code docs (opens in a new tab)Dynatrace synthetic monitoring docs (opens in a new tab)
What a longer user journey costs
Per-action billing puts a price on every step, so teams shorten the journey to protect the budget and stop monitoring the part of checkout that actually breaks.
How Checkly answers it: Checkly bills per check run, not per step, from one included pool. Published rates are $5 per 1,000 browser check runs and $2 per 10,000 API check runs. Put your real step count, frequency, and location list against both rate cards.
VerifyCheckly pricing (opens in a new tab)Dynatrace pricing (opens in a new tab)
How much platform you need around the synthetics
Consolidating on one vendor is a real advantage. It is only the wrong trade when the consolidated module is the weakest part of the estate for the job you care about.
How Checkly answers it: Checkly is scoped to outside-in synthetic monitoring and sits beside whichever observability backend you run, sending and receiving OpenTelemetry traces.
VerifyCheckly synthetic monitoring docs (opens in a new tab)Checkly traces docs (opens in a new tab)
Coverage of internal and non-HTTP endpoints
Most estates have services that are not a public URL: internal APIs, brokers, DNS records, and nightly jobs that fail silently.
How Checkly answers it: URL, TCP, DNS, ICMP, and heartbeat monitors cover those, and private locations reach services behind a firewall.
VerifyCheckly uptime monitoring docs (opens in a new tab)Checkly locations docs (opens in a new tab)
Criteria come from the evaluation questions Checkly hears most often in Dynatrace conversations. Statements describe Checkly's own behaviour; Dynatrace capabilities and rates should be confirmed against Dynatrace's documentation and pricing page, which change independently of this page. Last reviewed .
Need more proof? Listen to the engineers
“Checkly was incredibly easy to integrate. Even our initial traces setup was quick, and the documentation was better than OTel’s own.”
“The Checkly CLI has enhanced our engineering team’s ability to quickly build, validate, and deploy an entire suite of checks from their local development environment.”
“Checkly is a fabulous developer tool. The flexible features and developer-friendly API made the integration super easy, and their support is friendly and knowledgeable.”
“We love Heartbeat Checks! They help us ensure that critical operations run to completion and on time. We had previously evaluated other platforms just for their heartbeat checks, so we are happy to see these within Checkly along with the API and browser checks.”
“We’ve been using Checkly for months and it’s been phenomenal. Super easy to set up, works flawlessly and intuitively. The team is super receptive and quick to help.”
“Checkly is incredible: it combines Pingdom, Ghost Inspector, and Assertible in the same app, and the insights are much more detailed.”
Frequently asked questions
Coming from Dynatrace?
Bring one journey. We will turn it into a Playwright check that runs locally, ships from CI, and costs the same whether it has three steps or thirty.
Prefer a step-by-step guide?Read the Dynatrace migration guide
We look at the clickpaths you actually rely on
Most teams have a handful of journeys that matter and a long tail nobody trusts. We start from the first list, not from an export of everything.
You see what the same coverage costs per run
Bring your step counts, frequencies, and location list. We put your numbers against both rate cards so the comparison is yours, not ours.
Your first checks ship as code
A working session that ends with specs in your repo, running in CI and deployed to production, rather than a slide deck.