Your server says 200.
Your checkout says no.
Playwright-based synthetic monitoring. VerLake runs your login, checkout and API checks against production every minute, alerts you when one breaks, and shows you the exact step that failed and why.
Failed 3 runs in a row on production. Step 4: "Place order" stayed disabled.
Passing again after 11 min. All 5 steps in 2.3s.
TypeError: cannot read 'taxRate' of undefined in checkout.3f9a.js, which was deployed 14 min ago. Check /api/tax/quote.If it runs in a browser, VerLake can watch it
Same outage.
Two very different dashboards.
A JS bundle throws, a button stays disabled, an SSO redirect loops, and the server keeps answering 200. Ping checks can't see any of it.
Uptime ping UP
- Server responded
- TLS certificate valid
- No idea whether anyone can buy anything
VerLake journey PASSING
- Signed in
- Added to cart
- Order placed and confirmed
What is synthetic monitoring?
Synthetic monitoring runs scripted checks against your application on a schedule, from outside, the way a customer would, so you find out a flow is broken before real users hit it.
Uptime monitoring asks "does the server answer?". Synthetic monitoring asks "can someone actually sign in, search and pay?". VerLake runs those scripts as real Playwright browser journeys and fast API checks, and keeps a timeline of every run.
| Synthetic monitoring | Real user monitoring (RUM) | |
|---|---|---|
| Traffic | Scripted, on a schedule | Real visitors |
| Finds problems | Before users do, even at 3 am with zero traffic | After users hit them |
| Best for | Critical flows, SLAs, pre-release checks | Performance across real devices |
Everything between
"it broke" and "it's fixed".
Real browser journeys
Real Chromium drives your real UI: SPAs, OAuth redirects, multi-step forms. Playwright's auto-waiting keeps false alarms down. You see every step's timing, the console output and the exact error.
- 1 · goto /login✓ 412ms
- 2 · fill credentials & submit✓ 1,180ms
- 3 · expect dashboard data visible✓ 640ms
Alerts that mean it
Get told after N consecutive failures, not on every blip, and again when it recovers.
API checks every 30s
Assert on status, latency, headers and body. A fast tripwire in front of your journeys.
Test it, watch it back
Every test run in the editor returns screenshots and a video replay, so you know the journey works before you schedule it.
AI writes it, AI explains it
Describe a flow and get a Playwright script. When a run fails, get the likely root cause and what to check next. Uses your own AI API key.
Status pages with incidents
A branded public page (logo, colour, custom CSS) fed by your monitors, with incident posts and updates. Growth plan and up.
Environments & your own repo
One script, every environment: variables are injected as process.env. Already have a suite? Point VerLake at your GitHub or Bitbucket repo and a npx playwright test command.
Teams, roles, tokens
Owner, Admin, Editor and Viewer roles. Google or GitHub sign-in, domain-restricted joining, and personal access tokens for scripting.
A spend cap, built in
Usage billing without the surprise bill. Set a ceiling and runs stop before you pass it.
If it runs in Playwright,
it runs on VerLake.
Write it, generate it, or bring it
Use the editor, describe the flow to the AI assistant, or point at your repo. Hit Test and watch the video replay.
Point it at an environment
Production, staging, per-tenant. URLs and credentials arrive as process.env, so one script covers every target.
Schedule it and get alerted
Journeys every 1 to 60 minutes, API checks every 30 seconds. Alerts after N consecutive failures, plus the step, console output and AI summary for every run.
import { test, expect } from '@playwright/test'; test('customer can check out', async ({ page }) => { await page.goto(process.env.APP_URL); await page.getByLabel('Email').fill(process.env.TEST_USER); await page.getByLabel('Password').fill(process.env.TEST_PASS); await page.getByRole('button', { name: 'Sign in' }).click(); await page.getByText('Trail Runner 2').click(); await page.getByRole('button', { name: 'Add to cart' }).click(); await page.getByRole('button', { name: 'Place order' }).click(); await expect(page.getByText('Order confirmed')).toBeVisible(); });
# Same script, different targets → process.env.* production APP_URL = https://shop.example.com TEST_USER = synthetic+prod@example.com TEST_PASS = •••••••• # secret staging APP_URL = https://staging.shop.example.com TEST_USER = synthetic+stg@example.com # or run straight from your repo repo github.com/acme/e2e command npx playwright test --grep @prod
monitor checkout-flow journey checkout.spec.js env production every 5 min timeout 60 s # 1–300 s alert after 3 consecutive failures + when it recovers api check /health/deep every 30 s assert status == 200 assert latency < 800 ms assert body contains "db":"ok"
Ask your AI assistant
what broke overnight.
Add VerLake to any MCP-compatible AI assistant or coding agent with a few lines of config. It reads your dashboard, runs and queue, and can create, pause, resume or run monitors when you ask.
{
"mcpServers": {
"verlake": {
"type": "http",
"url": "https://app.verlake.com/api/mcp",
"headers": { "Authorization": "Bearer vlk_pat_YOUR_TOKEN" }
}
}
}get_dashboardlist_monitorsget_monitorlist_runsget_runlist_projectsget_projectlist_environmentsget_environmentget_queue_statuscreate_monitorupdate_monitorduplicate_monitorpause_monitorresume_monitorrun_monitor_nowTwo failures, both checkout-flow, at 02:10 and 02:15. "Place order" never enabled, with a
TypeError in checkout.js. Passing again since 02:20, after the rollback.Created checkout-flow (staging). It passed all 5 steps in 2.3s.
The flows that cost you
money when they break.
Login flow monitoring: know sign-in works before users try it
SSO redirects, MFA screens and feature-flagged dashboards are where "it works on staging" goes to die.
- Sign in through OAuth pop-ups and redirects
- Check the dashboard loads data, not a spinner
- Run the same journey against every tenant
- Publish the result on a status page
await page.getByRole('button', { name: 'Continue with Google' }).click(); // SSO pop-up handled by Playwright await expect(page.getByTestId('revenue-chart')).toBeVisible(); await expect(page.getByText('No data')).not.toBeVisible();
Checkout monitoring: every broken minute is lost revenue
Payment widgets, tax services and inventory calls: third parties you don't control but still get blamed for.
- Search, add to cart, reach payment
- Catch a disabled "Place order" before customers do
- API check on pricing every 30 seconds
- A step timeline that shows which dependency slowed down
await page.getByPlaceholder('Search').fill('trail runner'); await page.keyboard.press('Enter'); await page.getByRole('button', { name: 'Add to cart' }).first().click(); await expect(page.getByRole('button', { name: 'Place order' })).toBeEnabled();
Agent desktop monitoring for Genesys Cloud & Amazon Connect
When the agent desktop won't load at 8:55 am, the whole floor sits idle. Script the agent's first five minutes and run them every few minutes.
- Agent sign-in to the Genesys Cloud or Amazon Connect CCP
- Softphone panel and queues render
- Set status to Available and verify it sticks
- Separate environments per region or business unit
await page.goto(process.env.CCP_URL); await page.getByLabel('Username').fill(process.env.AGENT_USER); await page.getByLabel('Password').fill(process.env.AGENT_PASS); await page.getByRole('button', { name: 'Sign in' }).click(); await expect(page.getByText('Available')).toBeVisible({ timeout: 20_000 });
Run Playwright tests on a schedule, without babysitting cron
A scheduled workflow or a cron box works right up until it silently stops, and nobody notices the checks aren't running.
- Point VerLake at your repo and your command
- 30–365 days of run history, depending on plan
- 30-day uptime and trend per project
- Pay only for the seconds the browser runs
# before: .github/workflows/e2e-prod.yml on: schedule: - cron: '*/5 * * * *' # best effort, may be delayed # after: VerLake monitor repo github.com/acme/e2e command npx playwright test --grep @prod every 5 min alert after 3 failures
VerLake or a cron job?
Most teams start by running Playwright on a schedule themselves. Here's what that costs in practice.
| Cron on a VM | GitHub Actions schedule | VerLake | |
|---|---|---|---|
| Shortest interval | Whatever you configure | 5 min, best effort | 30s API · 1 min journeys |
| Alerting | Build it | Workflow failure email | ✓ After N failures + recovery |
| Browser infrastructure | You patch and scale it | Cold start every run | ✓ Pooled Chromium, managed |
| History and uptime % | Build it | Log retention only | ✓ 7–365 days, 30-day trend |
| What failed, in one screen | grep the logs | Scroll the job log | ✓ Step, console, AI summary |
| Customer status page | No | No | ✓ With incidents |
| Ask it from your AI assistant | No | No | ✓ 16 MCP tools |
| 5 × 30s journeys every 30 min | VM plus your time | Runner minutes plus your time | $29/mo |
Pay for browser seconds,
not seats.
Same product on every plan. You pay for the time a browser actually runs your checks. Queue time is free.
A login check usually takes 5–15s, a full checkout 25–60s, and an API check about 1s.
Free
Prove it on a real journey
- 40,000 seconds, one time
- About 800 checks
- 7-day history
- 1 member
- AI assistant (your own key)
Starter
Your critical paths, covered
- 400,000 seconds/month
- About 8,000 checks
- 30-day history
- 3 members
- Email support
Growth
For teams that ship daily
- 1,500,000 seconds/month
- About 30,000 checks
- 90-day history
- Unlimited members
- Public status pages
- Priority email support
Scale
Broad coverage, tight intervals
- 4,000,000 seconds/month
- About 80,000 checks
- 365-day history
- Unlimited members
- Dedicated support channel
Beyond your plan: $0.10 per 1,000 seconds, with a spend cap you control. SSO/SAML, volume pricing or dedicated infrastructure? Talk to us →
Who monitors the monitor?
You're trusting us to be awake when your product isn't. Here's exactly how a check gets run.
Every run is queued durably
Scheduled runs go onto a message queue before a worker takes them. A busy or restarting worker can delay a check but never loses it.
We drain, we don't kill
When we ship, workers finish in-flight runs before stopping, and new runs wait in the queue. Our deploys never become your false alarms.
A fresh browser context per run
No cookies, cache or session leak between runs or between customers. Hard timeouts (1–300s) on every run, and a visible banner if the queue ever falls behind.
What we're building next.
Slack & webhooks
Send the same alerts to the channels your on-call team already watches.
Replay every failure
Screenshots and video kept for failed scheduled runs, not only editor tests.
Multi-region
Run the same journeys from several locations and compare results by region.
Reliability, explained
without the jargon.
What is synthetic monitoring?
How it works, the kinds of checks, and how to choose which journeys to monitor first.
Read more → COMPARISONSynthetic vs real user monitoring
What each one catches, what each misses, and why most teams end up running both.
Read the guide → HOW-TOBuild a user journey monitor with Playwright
Project, script, schedule and alerts, step by step with screenshots: from an empty account to a live check.
Read the guide →How much downtime does your SLA allow?
What is synthetic monitoring?
Synthetic monitoring runs scripted checks against your application on a schedule, from outside, so you find out a flow is broken before real users hit it. VerLake runs those scripts as real Playwright browser journeys and API checks.
How is synthetic monitoring different from uptime monitoring?
Uptime monitoring checks that a URL answers, usually with HTTP 200. Synthetic monitoring performs the multi-step journey a user would, such as logging in or checking out, so it catches failures where the server is up but the product is broken.
What exactly is an execution-second?
One second of a browser (or HTTP client) actually running your check. A 30-second journey uses 30 seconds. Time waiting in the queue is never counted.
How do alerts work?
Choose how many consecutive failures count as "down", so one flaky run doesn't page you. VerLake tells you when the monitor starts failing and again when it recovers.
How often should synthetic checks run?
Revenue-critical journeys such as login and checkout usually run every 1 to 5 minutes, and supporting flows every 15 to 60 minutes. API checks can run every 30 seconds as a fast tripwire.
Do I need to know Playwright?
No. Describe the flow in plain English and the AI assistant writes the script, then helps fix it using your last test run. The assistant uses your organization's own AI API key, which you add in settings.
Can I use my existing Playwright tests?
Yes. Paste a spec into the editor, or connect a GitHub or Bitbucket repository and give VerLake the command to run.
What do I see when a check fails?
The step that failed, how long every step took, the browser console output, the error, and an AI summary of the likely root cause. When you test a journey in the editor, you also get screenshots and a video replay.
How does per-second pricing compare with per-check pricing?
Many tools charge per check run regardless of how long it takes. VerLake charges for the seconds a check actually runs, so short checks cost less and you never pay for queue time.
What happens at my spend cap?
Runs stop before you pass it, so you never get a bill you didn't agree to. You can raise the cap or change plan at any time.
Do you test phone calls or IVR?
No. VerLake tests what happens in a browser, including agent desktops like the Genesys Cloud UI or the Amazon Connect CCP. It doesn't place calls or navigate voice menus.
Can an AI assistant manage my monitors?
Yes. VerLake includes an MCP connector. Create a personal access token, add VerLake to any MCP-compatible AI assistant, and it can list runs, summarise failures, and create, pause or run monitors for you.
Find out what your users see.
Before they tell you.
40,000 free seconds: about 800 real checks on your real product. No credit card.