Synthetic Monitoring in Practice: Uptime Checks and Transaction Scripts

Synthetic Monitoring in Practice: Uptime Checks and Transaction Scripts

Uptime monitoring only answers "is the site down?". Synthetic monitoring goes further: it actively sends simulated requests and operations from probe locations around the globe, replaying the full path of a real user — clicking, logging in, placing an order — so problems are caught before users feel them. As Datadog defines it, synthetic tests observe system and application performance using simulated requests and actions from around the globe, covering network layers such as HTTP, SSL, DNS, WebSocket, TCP, UDP, ICMP, and gRPC, and alerting on regressions, broken features, high response times, and unexpected status codes.

Start with uptime checks

The lightest form of synthetic monitoring is the uptime check. Tools like UptimeRobot request your URL at fixed intervals from multiple locations, checking status codes, response time, and even searching the page for a keyword. When rolling this out, cover at least three layers:

1. HTTP check: verify the homepage returns 200 with expected content — the most basic liveness probe.
2. Keyword check: request the page and confirm it contains specific text (such as a login form or product title), catching "200 but broken content" cases.
3. Multi-location check: choose at least 3 locations overlapping your user distribution, so a single-location probe can't miss a region-specific failure.

Balance check frequency between detection speed and cost/false positives. Once a minute suits critical transaction pages, 5 minutes suits typical sites, and 10-30 minutes suits low-traffic content pages.

Browser transaction scripts

Uptime checks cover a single request and can't validate business flows. Browser transaction tests use a headless browser to record and replay critical paths — for example: open homepage → search a product → add to cart → checkout. Their real value is catching "backend fine but frontend broken" failures, such as a dead button, a script error, or a form that won't submit.

On platforms like Checkly or Datadog, transaction scripts support both code-first (Playwright/Puppeteer) and recording approaches. Start with the 5-10 highest-value journeys, prioritizing login, payment, and signup — flows where a break means lost users — rather than chasing script count. Avoid depending on external test data and use deterministic selectors so page tweaks don't cause false alarms.

The most common pitfall in scripts

The usual failure is not a wrong assertion but a brittle selector. These two lines make the point:

// Fragile: tied to a specific class, breaks on a redesign
await page.click('.add-to-cart-v2');

// Robust: locate by role plus text, close to a real user's click path
await page.getByRole('button', { name: 'Add to cart' }).click();

Likewise, do not use real registered accounts for tests. Have the environment under test provide test-only mock data, so each run does not create real orders or emails.

Choosing a tool: a comparison table

For a small independent site, the free tier of UptimeRobot plus two Checkly browser scripts is a low-cost combo: the former catches "the site was down and nobody knew", the latter guards the checkout journey. You can change tools later, but having at least one automated check from day one matters most.

Global locations and alerting

Synthetic alerting is closely tied to probe locations. Datadog lets you run tests from managed or private locations; private locations can also monitor internal APIs and services not exposed to the public internet. Two things to keep in mind when configuring alerts:

• Consecutive failure logic: a single failure can be network jitter. Configure "N consecutive failures" or a failure-rate threshold before alerting to cut false positives.
• Tiered notification: route minor anomalies to email/IM and page by phone/SMS only for core-business outages, matching the severity tiers in the monitoring and alerting guide.

Woken up at 2 a.m.: a real alerting post-mortem

A small cross-border e-commerce team was first rescued by synthetic monitoring at 2 a.m. Their rule was "notify after 3 consecutive failures", at a 5-minute interval. That night the payment gateway callback started returning 500 at 2:03, triggered email plus Slack at 2:18, and the on-call person was up by 2:25 — saw it was third-party gateway throttling, raised the quota in the dashboard, and recovered by 2:40 with users barely noticing.

The episode shows two things: the "consecutive failure" threshold keeps a one-off blip from waking the whole team, and multi-location probes let you tell "down everywhere" from "down in one region" — that night only the US East location alerted, pointing at a regional link problem rather than the server itself.

Complementary to real user monitoring

Synthetic monitoring is the "dress rehearsal"; real user monitoring (RUM) is the "post-mortem". The two are complementary. Synthetic data is stable, comparable, and free of privacy burden, making it a good observation basis for SLOs; RUM reflects the real distribution of devices, networks, and user behavior. In the SLO/SLI template, availability SLOs are usually measured with synthetic checks, while performance SLIs fit RUM data better.

16IDC Take

For independent sites and small teams, synthetic monitoring has a great return on investment: a free-tier UptimeRobot plus a few browser transaction scripts covers the most common outage — "the site was down and nobody knew". For tool selection see the website monitoring tool selection guide, and for self-hosted setups see deploying Uptime Kuma. If you already use the Grafana stack, check Grafana Cloud cost attribution to understand how synthetic check spend is billed, and see RUM and Core Web Vitals monitoring for the frontend view. See more in the Monitoring & Alerting category.

Source: https://docs.datadoghq.com/synthetics/
Reference: Checkly docs https://checklyhq.com/docs/; Playwright locator guide https://playwright.dev/docs/locators; Grafana Synthetic Monitoring https://grafana.com/docs/grafana-cloud/monitor-synthetic-monitoring/