Recorder-and-Selenium is the old wayCode-first Playwright is the new one
Uptime.com is a broad reliability suite, but its transaction monitoring is a no-code recorder with Selenium IDE import, and its results stay inside Uptime.com. Yorker runs native Playwright defined as code, and emits OpenTelemetry from every run into your own backend: the part Uptime.com has no answer for.
Last verified 2026-05-15
# Uptime.com: recorder / Selenium IDE
# Captured via Chrome extension
step open /login
step type #email [email protected]
step click button[type=submit]
# Yorker: native Playwright as code
// @step: Log in
await page.goto('/login');
await page.fill('#email', process.env.TEST_USER);
await page.click('button[type=submit]');
Why teams move from Uptime.com to Yorker
Uptime.com covers a lot of ground. Engineering teams leave for a specific reason: the scripting model is dated and the results never reach the rest of their observability stack.
A recorded or Selenium-imported journey is not code your team reviews in a pull request. Yorker checks are Playwright in YAML: diffable, code-reviewed, versioned with the app they test. Recorder blobs drift silently; code does not.
Uptime.com transaction checks lean on the Selenium model. Playwright has overtaken it on reliability, speed, auto-waiting, and ecosystem momentum. Building new journey coverage on a recorder/Selenium base is building on the tooling teams are migrating away from.
Uptime.com has no OTLP export. A failed synthetic check cannot be correlated with the backend trace, metric, or log that explains the failure. Yorker emits OTel from every run, so a synthetic span sits next to the application spans that caused it.
Uptime.com checks are authored in its UI and managed via API. Yorker is Monitoring as Code: definitions live in your repository and deploy through CI with the rest of your infrastructure. Reviewable, revertible, owned by the team.
With Yorker private locations, check telemetry stays on your network and flows to your OTel backend; it does not pass through Yorker's SaaS. That is a stronger data-path guarantee than a vendor-hosted dashboard model.
Uptime.com bundles many products; you adopt and pay for the whole suite. Yorker does synthetic monitoring deeply and hands the data to the tools you already run for status pages, RUM, and incident response. Focus over breadth when the breadth is not what you need.
Feature-by-feature comparison
Uptime.com's public pricing is driven by a plan calculator rather than fixed published tiers, so this table compares capabilities against Yorker's platform plan. The decisive differences are the scripting model (recorder/Selenium vs native Playwright) and OTel export.
| Capability | Yorker Platform plan | Uptime.com Synthetic / transaction |
|---|---|---|
HTTP / uptime checks Verify URL availability and response. | Included | Included |
Browser engine What drives multi-step user journeys. | Native Playwright | Recorder + Selenium import |
Scripting model How a journey is defined and reviewed. | Playwright code in YAML | Recorder / step editor |
OpenTelemetry export OTLP metrics, traces, logs to any backend. | Included, OTel-native | Not supported |
W3C trace propagation traceparent injected into check requests. | Always on | Not supported |
Private locations Run checks from inside your network. | Included (outbound-only) | Containerised probe (Docker/K8s) |
Monitoring as Code Check definitions in source control. | YAML (CLI) | API only |
Screenshot filmstrip Per-step visual evidence on every run. | Included | Step screenshots |
Check interval Minimum frequency between runs. | 30s – 60m | 1-minute minimum |
Hosted locations Global probe regions out of the box. | 14 regions | Multiple regions |
Features verified May 15, 2026 from uptime.com, uptime.com/private-location-monitoring, and Uptime.com support/extension documentation. Transaction checks use a no-code Chrome recorder and step editor with Selenium IDE import; private location monitoring is a containerised probe (Docker/Kubernetes); no OpenTelemetry export or Terraform provider is documented. Verify current pricing at uptime.com. Yorker platform plan pricing at /pricing. Spot something that's changed? Email [email protected].
Moving from Uptime.com
We'll do most of the work. Point the importer at your existing check definitions and it emits Yorker YAML with the 80% that translates cleanly, flagging everything it can't auto-convert with inline comments you can review.
yorker import --from uptime-com ./uptime-com-export.jsonExport your check configuration from the Uptime.com API and point the importer at it. Uptime/HTTP checks translate directly into Yorker YAML. Transaction checks (recorder output or Selenium IDE scripts) are flagged with their documented steps and assertions and scaffolded as Playwright starters; each is a short rewrite, not an auto-conversion.
What to watch for
- Recorder / Selenium scripts do not auto-convert
Uptime.com transaction checks are recorder output or imported Selenium IDE scripts. Yorker runs native Playwright, which is a different (and more capable) model. The importer captures each transaction's intent (the steps and assertions) as a documented Playwright scaffold, but each journey is rewritten, not machine-translated. The logic of what you test transfers; the syntax does not.
- Private locations are a different deployment
Both tools can run inside your network, but the shape differs. Uptime.com deploys a containerised probe (Docker/Kubernetes) that runs the full check suite locally. Yorker's private location agent is outbound-only and polls for work, with no inbound rules. Plan the agent rollout as a fresh deployment rather than a lift-and-shift of the Uptime.com container.
- No OTel today means a reporting-flow change
If your team consumes Uptime.com results inside Uptime.com's own dashboards and reports, moving to Yorker shifts that telemetry into your OTel backend instead. That is the point of the move, but it is a workflow change for whoever reads the reports, not just a tooling swap. Decide where synthetic data should live before cutting over.
What you keep
Your uptime/HTTP check URLs and intervals map directly into Yorker YAML.
Your transaction test intent: the flows, steps, and assertions you recorded become the basis for Playwright checks, even though the scripting model changes.
Your alert contacts (email, SMS, PagerDuty, Slack, webhook) pre-fill in the generated Yorker alert rules.
Your team's knowledge of which journeys matter: that lives in people, not in the recorder output.
Where Uptime.com is strongest
No tool is the right answer for every team. Here's where Uptime.com genuinely leads today — if your use case matches, start there.
Uptime.com bundles uptime, transaction monitoring, API checks, page-speed, real user monitoring, and hosted public status pages under one login. If you want a single vendor covering all of that, especially customer-facing status pages, Uptime.com delivers a wider surface than Yorker, which is focused on synthetic telemetry and does not include a built-in status page today.
Uptime.com's Chrome recorder lets a non-technical user click through a journey and produce a check without writing code. For teams where the person defining checks is not an engineer, that recorder is a genuine advantage. Yorker is code-first Playwright, deliberately built for engineers and CI, not point-and-click authoring.
Uptime.com is a mature commercial product with polished SLA reporting and a long track record. If your stakeholders already consume Uptime.com reports or compliance artifacts, there is real institutional switching cost there. Yorker is the newer entrant; its advantage is architectural, not tenure.
Frequently asked
What's the core difference between Yorker and Uptime.com?
Scripting model and telemetry. Uptime.com transaction checks are a no-code recorder plus Selenium IDE imports, and results stay inside Uptime.com. Yorker runs native Playwright defined as code in YAML, and emits OpenTelemetry from every run into your own backend. If you want recorder-authored checks in an all-in-one suite, Uptime.com fits; if you want code-first checks and OTel-native data, that is Yorker.
Does Uptime.com use Playwright?
No. Uptime.com transaction monitoring is built on a no-code Chrome recorder and step/command editor, and it can import Selenium IDE scripts. Playwright has effectively superseded Selenium for modern browser automation in reliability, speed, and ecosystem. Yorker runs vanilla Playwright as a library dependency.
Does Uptime.com support OpenTelemetry?
Not in its documented feature set. Uptime.com check results are consumed in Uptime.com's dashboards, reports, and integrations; there is no OTLP export that puts synthetic results into ClickStack, Grafana, Honeycomb, or another OTel backend alongside your application traces. Yorker is OTel-native and propagates W3C traceparent so synthetic runs show up as spans in your distributed traces.
Both have private locations: are they the same?
Similar goal, different shape. Uptime.com deploys a containerised probe (Docker/Kubernetes/Ubuntu/PhotonOS) that runs the check suite inside your network. Yorker's private location agent is outbound-only and polls the control plane for work, so it needs no inbound firewall rules and telemetry never transits Yorker's SaaS. Treat the migration as a new agent deployment, not a container port.
Can I reuse my Uptime.com transaction checks?
Not directly. Recorder output and Selenium IDE scripts cannot be auto-converted to Playwright. The Yorker importer documents each transaction's steps and assertions as a Playwright scaffold so you know exactly what each rewrite must achieve. Most transaction checks are short enough that the Playwright rewrite is well under an hour each.
Does Yorker replace Uptime.com's status pages?
No. Yorker does not include a built-in public status page today. If you rely on Uptime.com's hosted status pages for customer communication, plan to keep them or adopt a dedicated status-page tool alongside Yorker. That is a genuine gap to weigh in your evaluation.
Related Reading
Native Playwright checks defined as code: the modern alternative to recorder and Selenium transaction monitoring.
How Yorker's OTel-native emission brings synthetic results into your own observability backend.
Outbound-only agents that keep check telemetry on your network instead of in a vendor dashboard.
Ready for code-first checks with OTel built in?
Start free, no credit card, and rebuild your first Uptime.com journey as native Playwright with OpenTelemetry flowing into your own backend.