---
title: 'Yorker vs Uptime.com'
description: 'Yorker vs Uptime.com: native Playwright browser checks defined as code with OTel-native telemetry into your own backend, versus a no-code recorder with no OpenTelemetry export. Capability comparison and migration.'
canonical_url: 'https://yorkermonitoring.com/compare/uptime-com'
---

# Code-first checks, OTel-native data

**Native Playwright, in your repo, in your backend**

Yorker runs native Playwright defined as code and emits OpenTelemetry from every run into your own backend, so synthetic results sit next to your application traces. Uptime.com authors transaction checks in a no-code recorder, and their results stay inside Uptime.com with no OTLP export: the part Yorker is built around.

Last verified 2026-06-13.

## How a journey is defined

Uptime.com captures journeys with a no-code Chrome recorder via a browser extension:

```
# Uptime.com: no-code recorder
# Captured via Chrome extension
step    open /login
step    type  #email  user@x.com
step    click button[type=submit]
```

Yorker defines the same journey as native Playwright code:

```
# 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

Engineering teams switch to Yorker for two things: browser checks they can review as code in their own repo, and synthetic results that reach the rest of their observability stack as standard OTLP. Uptime.com gives them neither: recorder-authored journeys and results that never leave its dashboards.

**Recorder output is hard to review.** A recorded 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.

**Native Playwright, not a no-code recorder.** Yorker runs vanilla Playwright with auto-waiting, network interception, and the full ecosystem behind it. Uptime.com transaction checks are captured in a no-code Chrome recorder: easy to start, hard to maintain, and impossible to review as code as your journeys grow.

**Results never reach your traces.** 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.

**Monitoring lives outside your repo.** 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.

**Your data lands in your backend, not a silo.** Uptime.com results live in Uptime.com. Yorker enriches each run (anomaly scoring, third-party attribution, traceparent) and emits it as standard OTLP into the backend you already run, so the synthetic signal lives alongside the rest of your telemetry instead of behind another vendor login.

**One focused tool, not a broad suite tax.** 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 (native Playwright as code vs a no-code recorder) and OTel export.

| Capability | Yorker (Platform plan) | Uptime.com (Synthetic / transaction) |
| --- | --- | --- |
| HTTP / uptime checks<br>Verify URL availability and response. | Included | Included |
| Browser engine<br>What drives multi-step user journeys. | Native Playwright | Point-and-click recorder (Chromium) |
| Scripting model<br>How a journey is defined and reviewed. | Playwright code in YAML | Recorder / step editor |
| OpenTelemetry export<br>OTLP metrics, traces, logs to any backend. | Included, OTel-native | Not supported |
| W3C trace propagation<br>traceparent injected into check requests. | Always on | Not supported |
| Private locations<br>Run checks from inside your network. | Included (outbound-only) | Containerised probe (Docker/K8s) |
| Monitoring as Code<br>Check definitions in source control. | YAML (CLI) | API only |
| Screenshot filmstrip<br>Per-step visual evidence on every run. | Included | Step screenshots |
| Check interval<br>Minimum frequency between runs. | 30s to 60m | Sub-1-minute |
| Hosted locations<br>Global probe regions out of the box. | 14 regions | Multiple regions |

Features verified June 13, 2026 from uptime.com, uptime.com/private-location-monitoring, and Uptime.com support/extension documentation. Transaction checks use a no-code Chrome recorder (Chromium) and step editor; 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 hello@yorkermonitoring.com.

## Frequently asked questions

### What's the core difference between Yorker and Uptime.com?

Scripting model and telemetry. Yorker runs native Playwright defined as code in YAML (diffable, code-reviewed, and versioned alongside the app it tests) and emits OpenTelemetry from every run into your own backend. Uptime.com transaction checks are authored in a no-code recorder, and their results stay inside Uptime.com with no OTLP export. Yorker gives you code-first checks and OTel-native data that lands next to your application traces.

### Does Uptime.com use Playwright?

No. Uptime.com transaction monitoring is built on a no-code Chrome recorder and step/command editor that produces journeys you cannot review as code. Yorker runs vanilla Playwright as a library dependency, so a journey is a code-reviewed script with auto-waiting, network interception, and the full Playwright ecosystem behind it.

### 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: the agent reaches the control plane, never the other way around. Treat the migration as a new agent deployment, not a container port.

### Can I reuse my Uptime.com transaction checks?

Not directly. Recorder output cannot be auto-converted to Playwright. You rewrite each transaction as a Playwright script: the test intent (steps and assertions) carries over, but the syntax does not. Most transaction checks are short enough that the Playwright rewrite is well under an hour each, and you end up with a journey your team can review in a pull request.

### How does Yorker fit with status pages and incident tooling?

Yorker focuses on synthetic monitoring and emits standard OTLP, so the check signal flows into the status-page, incident, and on-call tooling you already run instead of being trapped behind another dashboard. A failed Yorker check is an OTel span and metric your existing pipeline can route, alert on, and surface, wherever your team already manages customer communication.

## 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.