Monitoring for e-commerce

Your homepage is up. Your checkout is not

Add to cart, shipping, payment, confirmation. Run the whole revenue path in a real browser, from the regions your customers buy from, every few minutes. Find the broken step before the drop shows up in tomorrow's conversion report.

Start for freeBook a demo
Real browsers22+ public regionsZero new tests to write
__checks__/revenue-paths.check.ts
1// __checks__/revenue-paths.check.ts
2import { PlaywrightCheck, Frequency } from 'checkly/constructs'
3
4// The checkout spec your team already maintains, promoted
5// to a production monitor.
6new PlaywrightCheck('revenue-paths', {
7 name: 'Checkout — every market',
8 playwrightConfigPath: './playwright.config.ts',
9 pwTags: ['@revenue'],
10 frequency: Frequency.EVERY_5M,
11 locations: ['us-east-1', 'eu-west-1', 'ap-southeast-1'],
12})

Trusted by teams whose revenue runs through a browser

Carhartt
Puma
Total Wine
Fanatics
GoFundMe
Hopper
Vio.com
“Within about 20 minutes of Checkly first detecting the issue, we identified where the problem was and had a fix ready to go.”
Joe Wright·Lead Automation Test Analyst · drivvn

Three ways your business is losing revenue while the dashboard stays green

Availability answers whether the site loads. Revenue depends on whether someone can finish paying, which is a different question and a longer one.

checkout

Uptime is green, checkout is broken

The storefront returns 200 while the payment step returns 500. A ping monitor sees the front door and stops there, which is exactly one step short of the part that takes money.

peak

The failure lands during the sale

Downtime on a launch day or a peak weekend is counted in orders, not minutes. Detection has to be automatic, because the traffic you planned for all quarter does not wait for someone to notice.

×17 markets

Every storefront is its own failure mode

Locale, currency, tax rules, payment methods, a regional CDN. A checkout that works in one country breaks quietly in another, and the aggregate conversion chart absorbs it for a week.

Checkly walks the purchase itself, per market, in a real browser. When it breaks, the alert names the step, the storefront, and the release it started on.

drivvn builds the digital retail platform behind online stores for Peugeot, Opel, Citroën, Vauxhall, and DS Automobiles across 17 countries, a platform that carried €709 million in vehicle sales in 2022. Their monitoring went from roughly 30,000 checks a month to more than a million API and browser checks a month.

“I’m really impressed with the improvements to our monitoring regimen that Checkly has delivered. Customer confidence has increased, and we’re confident that Checkly is helping drivvn scale as we roll out new stores and enter new markets.”

Peter Brown

CEO · drivvn

The checkout flow, as a spec you already own

If your team writes Playwright, the monitor is already written. Point Checkly at your existing config, tag the specs that touch revenue, and the tests that gate a merge start running against production on a schedule.

  • Real Chromium against real production, so it fails where a customer would
  • Each step timed separately, so you see which one got slow before it broke
  • Gateway test mode exercises the real payment path without placing a real order
  • No second suite to maintain: the same file gates CI and monitors production
e2e/checkout.spec.ts
1// e2e/checkout.spec.ts
2import { test, expect } from '@playwright/test'
3
4test('guest checkout completes @revenue', async ({ page }) => {
5 await test.step('add to cart', async () => {
6 await page.goto(`${process.env.BASE_URL}/products/tactical-jacket`)
7 await page.getByRole('button', { name: 'Add to cart' }).click()
8 await expect(page.getByTestId('cart-count')).toHaveText('1')
9 })
10
11 await test.step('shipping', async () => {
12 await page.getByRole('link', { name: 'Checkout' }).click()
13 await page.getByLabel('Email').fill('probe@acme-monitoring.dev')
14 await page.getByLabel('Postal code').fill('10115')
15 await page.getByRole('button', { name: 'Continue to payment' }).click()
16 })
17
18 await test.step('pay', async () => {
19 // Gateway test mode: a real transaction path, no real order.
20 const card = page.frameLocator('iframe[title="Secure card input"]')
21 await card.getByLabel('Card number').fill('4242 4242 4242 4242')
22 await page.getByRole('button', { name: 'Pay now' }).click()
23 })
24
25 await test.step('order confirmed', async () => {
26 await expect(page.getByText('Order confirmed')).toBeVisible()
27 await expect(page.getByTestId('order-total')).toHaveText('€129.00')
28 })
29})

Every storefront, every market. Generated, not clicked

Seventeen markets configured by hand in a UI is seventeen chances to forget one. A loop over your storefront config produces a check per market from a single spec, each running from the regions that market sells into.

  • One spec, one check per market, generated from the config you already keep
  • Per-market base URL, currency, and locale injected as environment variables
  • Each storefront watched from the regions its own customers buy from
  • A new market is a new line in a config file and a pull request
__checks__/storefronts.check.ts
1// __checks__/storefronts.check.ts
2import { PlaywrightCheck, Frequency } from 'checkly/constructs'
3import { storefronts } from './storefronts.config' // one entry per market
4
5// Add a market by adding a line, then opening a pull request.
6for (const store of storefronts) {
7 new PlaywrightCheck(`checkout-${store.locale}`, {
8 name: `Checkout — ${store.country}`,
9 groupName: 'Revenue paths',
10 playwrightConfigPath: './playwright.config.ts',
11 pwTags: ['@revenue'],
12 frequency: Frequency.EVERY_10M,
13
14 // Run from where those customers actually buy
15 locations: store.regions,
16
17 environmentVariables: [
18 { key: 'BASE_URL', value: store.baseUrl },
19 { key: 'CURRENCY', value: store.currency },
20 ],
21 })
22}

When a third party breaks your checkout at 2am, nobody has to guess

Half the money path isn't your code. The commerce platform, the payment gateway, the tax and shipping APIs can all take checkout down while every service you deploy stays healthy. Checkly catches the failure, and Rocky AI reads the evidence and names the dependency, so the incident starts at “Shopify is returning 503s” instead of an hour of blaming your own release.

  • API checks watch every dependency the checkout calls: commerce, payments, tax, shipping
  • Retries from a second region confirm it is the dependency, not a network blip
  • Rocky AI reads the error and the trace, then points at the failing service
  • The alert carries the evidence, so nobody debugs the wrong stack at 2am

Shoppers find out from you, not from Twitter

During an outage the status page is the second thing customers check and the last thing anyone remembers to update. Wire it to the checkout check instead. The incident opens the moment the flow breaks, subscribers are notified, and it closes itself on recovery. Support stops fielding “is your site down?” and starts handling the orders that actually failed.

  • Driven by the checkout check, not by a ping on the homepage
  • Your own domain and branding, public or private
  • Opens, notifies subscribers, and resolves without anyone posting
  • One card per market, so a broken DE storefront does not read as a global outage

More on status pages →

It plugs into the stack you already run

Checkly is the synthetic layer, not another silo. Results flow out to your metrics, traces, and incident tooling through native integrations and raw webhooks.

Playwright checks

Real Chromium against real production, so the check fails where a customer would.

Learn more

Global locations

Run each storefront from the regions its customers buy from, not from one datacenter.

Learn more

Vercel

Checks fire on every deployment, so a broken cart never survives a Friday release.

Learn more

GitHub Actions

Gate the merge on the same checkout spec that monitors production.

Learn more
Slack

Slack

Route each market to the team that owns it instead of one firehose channel.

Learn more
PagerDuty

PagerDuty

Incidents open and auto-resolve with your escalation policy when revenue paths break.

Learn more

Status pages

Tell customers what is happening on your own domain before support has to.

Learn more

Dashboards

One view per market or per brand, shareable with the people who ask about conversion.

Learn more

Traces

Connect a failing payment step to the backend span that caused it.

Learn more

Alerting

Retries across regions confirm a checkout failure before it pages anyone at 2 a.m.

Learn more

Rocky AI

Reads the failed run and its trace, then names the dependency that broke the sale.

Learn more

A broken cart is a clock, not a ticket

Every minute checkout is down is revenue that does not come back, which is why none of the steps after detection can wait for a person. The check confirms the failure across regions, pages the team that owns that market, opens the incident your shoppers are refreshing, and hands over the trace below. Nobody in that sequence had to remember anything.

00:00confirmed across regions00:00incident opens for shoppers00:01the cause has a name

And here is that trace. The checkout is timed span by span, so the conversation starts at the payment iframe or the shipping call rather than at “can anyone else reproduce this?”

See how AI analysis reads a failure →

Commerce teams, on Checkly

“Checkly came in because before that, whenever we had an incident, someone would have to manually notify us instead of it being automated. With Checkly, our incident detection is now automated, which saves us time and ensures faster response.”

Gus Fune

CTO · BÆRSkin Tactical Supply Co.

“The process of getting set up for the first couple of checks with Checkly was very simple and the onboarding was nice.”

Joe Wright

Lead Automation Test Analyst · drivvn

“With Playwright and Checkly, writing and maintaining tests is much easier. We get the benefits of synthetic monitoring using tools our engineers already know, and migrating was seamless since our suite was already written in Playwright.”

Dale French

Engineering Manager · Vio.com

“Checkly is super easy to use and fits perfectly in our toolchain. We monitor our Vercel projects on preview and production to catch issues earlier and we can trust that we are the first ones to know about problems in production.”

Andreas Wixler

CTO & Founder · FINN

“Quality isn’t just a QA problem, and that’s something we try to work into every process across the company.”

Joe Wright

Lead Automation Test Analyst · drivvn

Frequently asked questions

How Checkly fits a commerce stack: test orders, credentials, multi-market coverage, and peak days.

Yes, and this is the usual setup. Point the check at your payment gateway’s test mode and use its test card numbers, or reserve a dedicated test SKU and a probe account that your order pipeline filters out downstream. The check exercises the same code path a customer does; only the settlement is sandboxed.

Credentials live in encrypted environment variables set at the check, group, or account level, and are referenced from your spec as process.env values. Nothing sensitive is committed to the repo, and you should be using gateway test cards rather than real card data in any case.

No. Write the checkout flow once and parameterize the pieces that differ by market: base URL, currency, locale, payment method. A loop over your storefront config generates one check per market from a single spec, each running from the regions that market actually sells into.

You can raise check frequency for the period that matters and use maintenance windows to suppress alerts during planned work, so a deploy does not page anyone and a sale gets watched more closely than a Tuesday.

The failing run captures a full screenshot, a video replay, and a trace, with each step timed separately so you can see whether the payment step broke or just got slow. AI root cause analysis reads that evidence and summarizes the likely cause.

Wire the checkout checks to a status page on your own domain. When the check fails the incident opens automatically and subscribers are notified; when it recovers it closes. Support and shoppers are reading the same status while your engineers are still working, which is the difference between a queue of “is checkout down?” tickets and a queue of real ones.

That is exactly what traces and Rocky AI are for. Checks emit OpenTelemetry spans, so a failing payment step links to the outbound call behind it, whether that is your gateway, your tax service, or your commerce platform. Rocky AI reads the run alongside that trace and names the dependency, so the first minute of the incident tells you whether to page your own team or open a ticket with a vendor.

Yes. Browser checks drive the storefront exactly as a shopper would, whatever renders it, and API checks cover the commerce and payment APIs underneath. Teams typically monitor both layers so a failure points at either the frontend or the service behind it.

Put a monitor on the path your revenue takes

Point Checkly at the Playwright config you already have, tag the checkout spec, and every storefront gets watched from the regions it sells into.

Start for freeBook a demo