Checkout monitoring: your server says 200, your checkout says no

What uptime checks miss

A ping asks one question: does the server answer? A login or checkout can fail while the answer is still HTTP 200. These are the failures customers find first:

A synthetic transaction catches these because it does what the customer does. It clicks the button, fills the form and checks the result. That is user journey monitoring, and login and checkout are the journeys that cost the most when they break.

How it works

1Write the journey, generate it, or bring it

Write a Playwright test in the editor. Or describe the flow in plain English in the AI tab and it drafts the script, using your organization's own AI API key. Already have tests? Point the project at a GitHub or Bitbucket repository and give the monitor a command such as npx playwright test --grep @prod.

2Point it at an environment

An environment holds the URL and the test account's credentials. VerLake injects them as process.env, so one script runs against production, staging or each tenant.

3Test it, then schedule it

Click Test Run and you get each step, the console output, screenshots and a video replay. Then choose an interval of 1, 5, 15, 30 or 60 minutes, a timeout of up to 300 seconds, and a failure threshold.

4Add a fast tripwire

Pair the journey with an API check on a pricing, inventory or health endpoint. It asserts on status, latency, headers and body, as often as every 30 seconds.

Example: sign in and reach payment

This journey signs in with a test account, adds a product to the cart and checks that "Place order" is enabled. It stops before paying. Each test.step names one part of the flow. The URL, labels and button names are placeholders, so adjust them to match your store.

import { test, expect } from '@playwright/test';

// Placeholder selectors: change the labels and names to match your store.
test('customer can sign in and reach payment', async ({ page }) => {
  await test.step('Open the store', async () => {
    await page.goto(process.env.APP_URL);
  });

  await test.step('Sign in', async () => {
    await page.getByRole('link', { name: 'Sign in' }).click();
    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 expect(page.getByRole('link', { name: 'My account' })).toBeVisible();
  });

  await test.step('Add a product to the cart', async () => {
    await page.getByPlaceholder('Search').fill('trail runner');
    await page.keyboard.press('Enter');
    await page.getByRole('button', { name: 'Add to cart' }).first().click();
  });

  await test.step('Reach payment', async () => {
    await page.getByRole('link', { name: 'Checkout' }).click();
    await expect(page.getByRole('button', { name: 'Place order' })).toBeEnabled();
  });
});

Signing in through SSO

For SSO login monitoring, swap the sign-in step for one that goes through your identity provider and back. Playwright follows the redirects like a real browser.

await test.step('Sign in through SSO', async () => {
  await page.getByRole('button', { name: 'Sign in with SSO' }).click();
  await page.waitForURL(/idp\.example\.com/); // your identity provider
  await page.getByLabel('Email').fill(process.env.SSO_USER);
  await page.getByLabel('Password').fill(process.env.SSO_PASS);
  await page.getByRole('button', { name: 'Sign in' }).click();
  await page.waitForURL(process.env.APP_URL + '/**');
  await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
});

What you see when a check fails

VerLake waits for the number of failures in a row you set, so one flaky run doesn't page anyone. Then it alerts you, and it tells you again when the journey recovers.

Every run records:

• the step that failed, and how long every step took
• the browser console output and the error
• an AI summary of the likely root cause, using your own AI API key

Runs stay in Run History, so you can compare a failure with the last good run. On the Growth plan and up, you can show login and checkout on a public status page with incident posts. With the MCP connector and its 16 tools, your AI assistant can list failed runs and summarise them for you.

Pricing

You pay for the seconds a check runs. Queue time is free. A login check usually takes 5 to 15 seconds and a full checkout 25 to 60 seconds.

A 30-second checkout journey every 10 minutes uses 129,600 seconds a month. A 10-second login check every 5 minutes uses 86,400. Both fit in Starter. Beyond your plan it's $0.10 per 1,000 seconds, with a spend cap you control. See full pricing.

FAQ