What your uptime check saw
GET https://app.acme.dev/ → 200 OK · 183 ms · SSL valid for 61 days. Status: Up. Everything green. Your status page agrees.
SYNTHETICS · BETA
Your homepage is up. Your checkout is not.
DevHelm runs your own Playwright specs and multi-step API checks on a schedule, from 4 regions. When one fails, you get the trace, the video and the exact step, not a red dot.
Your own Playwright specsPlaywright 1.62.14 regionsTrace, video and HAR kept 14 days
WHY SYNTHETICS
Your uptime check saw a 200. Your customer saw a spinner.
Same app, same minute. A ping cannot click a button, so it passes straight over failures like these.
- A signup form that returns 200 and silently drops the confirmation request.
- A Stripe card iframe that stops mounting after a CSP header change.
- A login that loops to /login?error=state after an Auth0 rule edit.
What a customer saw
8 steps. Step 7 click "Pay $29" → POST /api/checkout/confirm returned 502 after 8.2 s. "Payment confirmed" never appeared. Status: Failed. Nobody in eu-west or ap-south has paid you since 03:12 UTC.
PLAYWRIGHT MONITORING
The spec you run in CI is the monitor you run in production
Upload your Playwright project, name the entry spec, and pick a schedule. Same selectors, same assertions, same @playwright/test.
- Your own specs, unchanged. If it passes with npx playwright test, it is a candidate check.
- Upload through the package API. Include the files the spec imports.
- Secrets reach the spec as process.env.NAME. DevHelm finds the names in your files, stores the values encrypted, and masks them in network logs, HAR, console and runner logs.
- Screenshots and video show whatever the page shows, so run the check with a dedicated test account.
- 1Upload your spec
- 2Pick regions and schedule
- 3First run, with its trace
import { test, expect } from '@playwright/test';
test('pro plan checkout completes', async ({ page }) => {
await test.step('Open login', () => page.goto('https://app.acme.dev/login'));
await test.step('Sign in', async () => {
await page.getByLabel('Email').fill(process.env.CHECKOUT_EMAIL!);
await page.getByLabel('Password').fill(process.env.CHECKOUT_PASSWORD!);
await page.getByRole('button', { name: 'Sign in' }).click();
});
await test.step('Open pricing', () => page.goto('https://app.acme.dev/pricing'));
await test.step('Start Pro', () => page.getByRole('button', { name: 'Start Pro' }).click());
const card = page.frameLocator('iframe[name^="__privateStripeFrame"]').first();
await test.step('Enter card', () => card.getByPlaceholder('Card number').fill('4242 4242 4242 4242'));
await test.step('Enter expiry and CVC', async () => {
await card.getByPlaceholder('MM / YY').fill('12 / 34');
await card.getByPlaceholder('CVC').fill('123');
});
await test.step('Pay $29', () => page.getByRole('button', { name: /Pay \$29/ }).click());
await test.step('Payment confirmed', () =>
expect(page.getByRole('heading', { name: 'Payment confirmed' })).toBeVisible({ timeout: 15_000 })
);
});checkout-monitor.zip
├── tests/
│ ├── checkout.spec.ts # entry spec
│ └── helpers/
│ └── stripe.ts
└── package.json
Entry spec: tests/checkout.spec.ts
Secrets: CHECKOUT_EMAIL, CHECKOUT_PASSWORDSAMPLE RUN REPORT
03:17 UTC. Checkout fails in two regions.
An illustrative checkout failure showing the evidence a run can capture. A failed run is a recording, so the first person who opens the alert sees the failure instead of trying to reproduce it.
- Screenshot: spinner on the Pay button, no error message shown to the user.
- Video of the whole run, and a Playwright trace with the DOM snapshot at every action.
- Network log (HAR): POST /api/checkout/confirm → 502 Bad Gateway after 8,204 ms.
- Network log (HAR): GET https://api.stripe.com/v1/payment_intents/pi_3Q… → 200 in 187 ms. The card step worked.
- Console: Uncaught (in promise) Error: confirm failed (502).
The run
checkout-pro-plan · Run run_8f3a91 · Failed · 41.3 s · started 2026-10-04 03:17:42 UTC · eu-west. Run run_8f3a92 in ap-south also Failed (39.8 s).
What failed
Step 7 of 8, click "Pay $29". Expected heading "Payment confirmed" within 15 s. Timed out at 15.0 s.
Flake or failure
Immediate retry, 1 attempt: failed again at the same step. Incident opened; alert sent to Slack #eng-alerts and PagerDuty.
What it tells you
The failure is after Stripe accepted the card and before your backend confirmed the order. Look at /api/checkout/confirm.
Evidence kept 14 days
screenshot 212 KB · video 41 s · trace 6.8 MB · console 14 lines · HAR 63 requests.
With the design-partner program
Design partners also get the AI SRE agent, installed by the DevHelm team. It starts from a failed run like this one and reports whether it is your code or a vendor, with the evidence attached.
MULTI-STEP API CHECKS
Chain the calls. Assert at every step.
A single GET proves a route exists. A sequence tests the contract: authenticate, create, read back, clean up. Name the request steps and assert their responses in your test; inspect the test outcome and recorded run evidence when it fails.
- Model the flow your integrators run: token, create, fetch, delete.
- Write assertions at each request and give the steps meaningful names. Review the test outcome and recorded runner evidence to identify the failed condition.
- Upload it the same way as a browser check: the files and an entry file.
- No browser, so every plan includes 10× as many API runs as browser runs.
- Same alerts and same run history as browser checks.
Authenticate
POST /oauth/token
Create invoice
POST /v1/invoices
Read invoice
GET /v1/invoices/:id
Clean up
DELETE /v1/invoices/:id
Sample invoice-roundtrip · 200 → 201 → 200 → 204 · 837 ms total
invoice-roundtrip Passed
5 min interval, us-east. 1 POST /oauth/token 200 212 ms · 2 POST /v1/invoices 201 388 ms · assert body.status == "draft" · 3 GET /v1/invoices/inv_2KxQ9 200 141 ms · assert body.total == 4900 · 4 DELETE /v1/invoices/inv_2KxQ9 204 96 ms. Total 837 ms.
Same check Failed at step 3
404. assert body.total == 4900 not evaluated.
WHERE IT RUNS
Pick one region. Or all four.
Checks run from us-east, us-west, eu-west and ap-south, and all four are on every plan. Choose regions per monitor.
- One run = one execution in one region. Two regions = two runs per schedule.
- Region results sit side by side, so "fails in eu-west and ap-south only" is one glance.
- Each region's traffic leaves from one fixed IP. We share the list on request, so you can allowlist it.
- Every run executes in its own gVisor sandbox. Internal networks, cloud metadata and other sandboxes are unreachable from it.
PRICING, IN RUNS
Count your runs before you create the check
Add your monitors below and see which plan covers them. Browser and API runs have separate monthly pools.
Recommended plan
Pro
$29 / month- Browser runs
- 11,520 / 15,000
- API runs
- 20,160 / 150,000
- Monitors
- 5
30-day month. One execution in one region is one run. Retries count too.
When included runs are used, new runs stop. No overage bill.
Worked example: the five default monitors
- Totals: Browser 11,520 runs · API 20,160 runs · 5 monitors.
- Recommended plan: Pro, $29/month. Browser 11,520 of 15,000 (77%). API 20,160 of 150,000 (13%). 5 of 20 monitors. Shortest interval used: 5 min, Pro's floor.
- Starter would be 192% of its 6,000 browser runs, and its floor is 10 minutes.
- When the included runs are used, new runs stop. No overage bill.
- The usage meter in the dashboard shows where you are.
- Retries count as runs, so leave room if you turn on immediate retry.
- One browser monitor every 5 minutes from one region is 8,640 runs a month. Every minute from one region is 43,200, which needs Team (45,000).
KEY FACTS
DevHelm Synthetics, in facts
What it is, what runs it, and where the edges are. Facts checked 2026-10-06.
- WHAT IT IS
- Playwright and multi-step API checks on a schedule.A check runs your own @playwright/test spec, or a sequence of HTTP requests with assertions, and records the result.Synthetics overview
- CHECK TYPES
- Two.Browser (Playwright) and multi-step API. HTTP, DNS, TCP, ping, heartbeat and MCP server checks are part of uptime monitoring and do not use synthetic runs.Browser checks, Multi-step API checks
- RUNNER
- Playwright 1.62.1, one sandbox per run.Each run executes in its own gVisor sandbox with a read-only root filesystem. Egress is limited to public HTTP, HTTPS and DNS.How runs execute
- WHERE IT RUNS
- 4 regions.us-east, us-west, eu-west, ap-south. One execution in one region is one run. Each region's traffic leaves from one fixed IP, shared on request.Regions
- HOW SPECS GET IN
- Upload through the package API.Upload the spec and its files, name the entry spec, and set secrets. Secrets reach the spec as process.env.NAME and are masked in network logs, HAR, console and runner logs.Uploading a spec
- EVIDENCE
- Kept 14 days on every plan.Screenshot, video, Playwright trace, network log (HAR) and console for every failed run.Run evidence
- ALERTS
- 20 integrations on every plan, Free included.Email, Slack, Discord, Microsoft Teams, Webhook, PagerDuty, Opsgenie, Telegram, Google Chat, Pushover, Mattermost, Splunk On-Call, Pushbullet, Linear, incident.io, Rootly, Zapier, Datadog, Jira, GitLab. A failed run opens an incident.Alert channels
- WHAT IT IS NOT
- Not RUM, not load testing, not inside your network.It does not observe real visitors, does not generate load, and runs from DevHelm's 4 regions.What Synthetics is not
FIT CHECK
Is Synthetics right for your team?
Built for small SaaS teams with a handful of journeys that must not break.
Strong fit when
- You have 3 to 30 engineers, customer-facing flows (signup, login, checkout, an API integrators call) and nobody whose full-time job is SRE.
- You already write, or can write, Playwright specs, and want them running outside CI.
- You depend on Stripe, Auth0 or an email provider and want to know when the flow breaks, not only when a vendor posts an incident.
Not the best fit when
- You need checks to run from inside your private network. Checks run from DevHelm's 4 regions.
- You need load testing or real-user monitoring. This runs scripted checks, not traffic.
- You need a contractual SLA on the monitoring itself today.
FAQ
Frequently asked questions
Specs, runs, regions and access. The docs have the rest.
What is the difference between synthetic monitoring and uptime monitoring?
Uptime monitoring checks that an endpoint responds. Synthetic monitoring runs a scripted user journey or API sequence and checks that it completes with the right result. DevHelm has both: uptime checks (HTTP, DNS, TCP, ping, heartbeat, MCP server) and Synthetics for Playwright and multi-step API checks.
Do I have to rewrite my Playwright tests?
No. Upload the spec you already run, with the files it imports, and name the entry spec. Secrets reach it as process.env.NAME. Specs that depend on local-only state (a seeded database, a mocked server) need a production-safe version.
What counts as a run, and what happens at my limit?
One execution in one region is one run, so two regions means two runs per schedule. Browser and API runs have separate monthly pools, and the usage meter shows where you are. When the included runs are used, new runs stop. No overage bill.
How often can checks run?
Free every 60 minutes, Starter every 10, Pro every 5, Team every minute, Business every 30 seconds, Enterprise every 10 seconds. Shorter intervals use more runs; the calculator above shows how many.
How do you handle flaky tests?
Turn on immediate retry: 0 to 10 attempts, off by default. When a spec fails on your app, DevHelm reruns it right away in the same region before deciding. A pass on retry is recorded as passed on retry; a repeat failure opens an incident. Retries count as runs.
Where do checks run, and can I allowlist your IPs?
From us-east, us-west, eu-west and ap-south. Each region's traffic leaves from one fixed IP. We share the list on request.
Can I monitor staging or something behind a firewall?
Staging works if it is reachable from the public internet on HTTP or HTTPS, for example behind basic auth or a token header. Anything reachable only inside your network can't be monitored today.
Is it production ready? What does "beta" mean here?
It's in beta. Runs, evidence and alerts work today; run limits and regions can still change, and we announce changes in the changelog first.
What is the AI SRE agent?
An investigation agent that starts from a failed run or check and reports whether it is your code or a vendor, with the evidence. It is available to design partners, installed and tuned by the DevHelm team. It is not self-serve and it does not change anything on its own.
Watch the flow, not the homepage
Access is by invitation. Book a 30-minute demo and we'll set up your workspace.