Explore documentation
  1. Welcome to Incidents 👋
  2. Frequently Asked Questions
  3. On-call scheduling and alerting
    1. Get started
    2. Slack and other integrations ↗
    3. Connecting external calendars
    4. Advanced guide
  4. Incident management
    1. Get started
    2. Post mortems
    3. Metadata & Catalog
    4. Screening alerts
    5. Reporting ↗
  5. Monitoring
    1. Get started
    2. Working with monitors
    3. Customizing monitors
    4. Monitor types
      1. Uptime monitor
      2. Keyword monitor
      3. Ping monitor
      4. Heartbeats
      5. Playwright monitor
      6. API monitor
      7. DNS monitor
      8. Domain expiration monitor
      9. SSL certificate monitor
      10. TCP/UDP port monitor
      11. Monitoring private networks
  6. Status pages
    1. Get started
    2. Advanced guide
  7. Incidents API
    1. Getting an API token
    2. Monitors
    3. Heartbeats
    4. On-call & incidents
    5. Status pages
    6. Metadata
    7. Integrations
    8. Team members
    9. Organization roles
    10. Usage
    11. Reporting

Playwright monitor

Set up fast and reliable end-to-end transaction monitoring for your web apps with Playwright-powered browser checks.

Getting started

Create your first Playwright scenario:

  • Navigate to Monitors → Create monitor.
  • Select Alert us when: Playwright scenario fails.
  • Use the following code:
Test that users can sign up on mobile
import { test, expect } from '@playwright/test';

test('mobile page contains Sign up', async ({ page }) => {
  await page.setViewportSize({ width: 360, height: 640 }); 
  await page.goto('https://betterstack.com/');
  const pageContent = await page.textContent('body');
  expect(pageContent).toContain('Sign up');
});

With this simple test, you can make sure that your customers can sign up from your landing page on mobile. Creating Playwright scenarios for critical user flows is a great way to protect yourself from regressions and unexpected issues.

Start monitoring your landing page today

Change the URL and the sign up button text in the example test above.

How to create Playwright scenarios?

We recommend using the Playwright Codegen or ChatGPT:

  • Playwright Codegen: Record end-to-end tests using VSCode or Playwright Inspector. Read more in the official Playwright guide.

  • ChatGPT: Generate your tests with the help of AI. Go to ChatGPT and start with this query:


Great starting query to use with ChatGPT
Write a Playwright test using test and expect in JavaScript:
- Set viewport to mobile device size
- Open betterstack.com
- Click Sign up button
- ...


Using environment variables

You can use passwords, secrets, and tokens securely in your scenarios by defining them as environment variables:

  1. Navigate to Monitors → Select a monitor → Configure → Advanced settings → Environment variables.
  2. Add variable names and values as needed.

To access defined variables in your scenario, use expressions like process.env.PASSWORD:

Test that users can sign in
import { test, expect } from '@playwright/test';

test('users can sign in', async ({ page }) => {
  await page.goto('https://app.example.com/');

  await page.getByLabel('E-mail').fill('user@example.com');
  await page.getByLabel('Password').fill(process.env.PASSWORD);
  await page.getByRole('button', { name: 'Sign in' }).click();

  await page.waitForURL('https://app.example.com/dashboard');
});

Adding instant retries of failing test

You can avoid flaky tests using retries in Playwright:

Retrying failing tests up to 2 times
import { test, expect } from '@playwright/test';

// Retries failing tests up to 2 times
test.describe.configure({ retries: 2 });

test('has title', async ({ page }) => {
  await page.goto('https://betterstack.com/')
  await expect(page).toHaveTitle(/Better Stack/)

  // Add some randomness to the results to test retry
  // A single test succeeds only in 50% of cases
  await expect(Math.random() > 0.5).toBeTruthy()
});

Using Playwright to monitor APIs

You can call your API directly using fetch and use custom Javascript to verify the results:

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

test('No expensive coffee in API', async () => {
  const URL = 'https://api.sampleapis.com/coffee/hot';
  const MAX_PRICE = 2.9;

  const response = await fetch(URL, {
    method: 'GET',
    headers: {
      'Authorization': `Bearer ${process.env.API_TOKEN}`,
      'Content-Type': 'application/json',
    },
  });
  console.debug("API Response:", response);
  expect(response.ok).toBeTruthy();

  const data = await response.json();
  console.debug("API JSON data:", data);

  const expensiveItems = data
    .filter(item => item.price > MAX_PRICE);

  if (expensiveItems.length > 0) {
    console.warn('🚨 Found expensive items:');
    expensiveItems.forEach(item => {
      console.warn(`- ${item.title}: $${item.price}`);
    });

    throw new Error(`Found ${expensiveItems.length} item(s) over $${MAX_PRICE}.`);
  }
});

Using console.log can provide additional info in case an incident is created.

Exporting metadata from your scenario

Your scenario can label the incident it opens by writing a JSON object to metadata.json in its working directory. The incident takes its metadata from the failing run that opens it, so later runs do not relabel it.

Recording which step failed
import { test, expect } from '@playwright/test';
import fs from 'fs';

let reason;

test.beforeEach(() => {
  reason = null;
});

test.afterEach(() => {
  if (reason) {
    fs.writeFileSync('metadata.json', JSON.stringify({ REASON: reason }));
  }
});

test('coffee API answers', async () => {
  reason = 'list_get_fail';
  const list = await fetch('https://api.example.com/coffee');
  expect(list.ok, `listing coffee returned ${list.status}`).toBeTruthy();

  const [first] = await list.json();
  expect(first?.id, 'the list returned no usable item').toBeTruthy();

  reason = 'details_get_fail';
  const details = await fetch(`https://api.example.com/coffee/${encodeURIComponent(first.id)}`);
  expect(details.ok, `coffee detail returned ${details.status}`).toBeTruthy();

  reason = null;
});

Naming each step before it runs labels a DNS failure, timeout or unexpected body with the step it happened in, and a passing run writes nothing. The incident then carries REASON: details_get_fail, which you can read there and filter incident reports by, like any other incident metadata.

Where and when to write the file

Write it in test.afterEach: a failing expect() throws immediately and a timed-out test is abandoned, so the end of your test and any finally block never run. afterEach still runs in both cases, though not when test.beforeAll fails.

Use the plain relative path metadata.json and write nothing beside it, which the sandbox refuses. The file survives the whole run, so with retries a later attempt that fails without setting reason ships the earlier label. A metadata.json written to the test output directory instead, through testInfo.outputPath() for example, is not read as metadata and is published as a publicly linkable artifact.

What Better Stack stores

Values are stored as text, nested objects and arrays as their JSON. A value that is empty, nested deeper than 32 levels or holding a number too large for a double is left out.

One run can export 30 keys, with keys up to 100 and values up to 1000 characters, and 4000 characters in total. Longer values are cut, later keys are dropped, and a file over 1 MB, or one that is not a JSON object, is ignored entirely.

Names are matched loosely, so Order ID, order_id and orderId count as one name. Your scenario cannot use a name your monitor already defines under Metadata, or one Better Stack sets itself: Monitor, Monitor pronounceable name, Monitor type, Monitor URL, Monitor required keyword, Origin, Escalation policy and Group. A name a Catalog relation adds is taken as well, matched exactly rather than loosely.

Metadata is never redacted, and a value can appear in the incident, its notifications and your reports, so keep secrets and personal data out of it. A few names Better Stack uses for alert details, such as Alert type, Operator and Query name, stay on the incident but never reach notifications.

Storing and querying data in Playwright scripts

Playwright monitors are stateless. For persistent storage or to react to previous states, use an HTTP Telemetry source and our SQL API.

Ingest data: Send your Playwright script's output, console logs, or custom event data as JSON events to an HTTP Telemetry source. This allows you to retain any custom data you extract, detailed records of each test run, or performance metrics.

SQL API: Leverage our SQL API to read any data you stored. You can use fetch() with FORMAT JSON to read the data directly in your Playwright monitor, enabling it to react to the previous state.

Alerts: Use the data to create custom alerting based on thresholds or detected anomalies in your Playwright script's performance or output.

Need help?

Please let us know at hello@betterstack.com.
We're happy to help! 🙏

Previous article

Cron and heartbeat monitor

Next article

API monitor