Synthetic monitoring proactively tests your application by simulating real user actions on a schedule — catching issues before actual users encounter them, rather than only learning about problems reactively.
Synthetic Monitoring vs Real User Monitoring
Synthetic monitoring runs scripted checks continuously regardless of actual traffic; real user monitoring (RUM) observes genuine user sessions — synthetic monitoring catches issues even during low-traffic periods when RUM might not surface a problem quickly.
What to Monitor Synthetically
- Critical business flows: login, checkout, core feature usage
- Key API endpoints your application depends on
- Anything where a silent failure would have significant business impact
Prerequisites
- A tool capable of scripted browser automation (e.g. Playwright or Puppeteer)
Step 1 — Install a Browser Automation Tool
npm install playwright
npx playwright install
Step 2 — Write a Synthetic Test for a Critical Journey
const { chromium } = require('playwright');
async function testLoginFlow() {
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://yourapp.com/login');
await page.fill('#email', '[email protected]');
await page.fill('#password', 'TEST_PASSWORD');
await page.click('#login-button');
await page.waitForSelector('#dashboard', { timeout: 10000 });
console.log('Login flow: SUCCESS');
await browser.close();
}
testLoginFlow().catch((err) => {
console.error('Login flow: FAILED', err);
process.exit(1);
});
Step 3 — Use a Dedicated Test Account
Never run synthetic tests against real customer accounts — create dedicated test accounts specifically for monitoring purposes, isolated from production customer data.
Step 4 — Run on a Schedule
crontab -e
*/5 * * * * /usr/bin/node /path/to/synthetic-test.js >> /var/log/synthetic-tests.log 2>&1
Step 5 — Alert on Failures
node synthetic-test.js || curl -X POST YOUR_ALERTING_WEBHOOK -d "Login flow synthetic test failed"
Integrate with your existing alerting system (see How to Set Up Effective Server Alerting) so a failed synthetic test triggers the same escalation path as other critical alerts.
Testing from Multiple Locations
For geographically distributed audiences, running synthetic tests from multiple regions can catch region-specific issues (CDN problems, regional network routing issues) that a single-location test would miss.
Measuring Performance, Not Just Success/Failure
const startTime = Date.now();
await page.goto('https://yourapp.com/login');
const loadTime = Date.now() - startTime;
if (loadTime > 3000) {
console.warn(`Slow page load: ${loadTime}ms`);
}
Track timing alongside pass/fail status, feeding this into your metrics system for trend visibility over time, not just point-in-time pass/fail checks.
Keeping Synthetic Tests Maintained
UI changes can break synthetic tests even when the underlying functionality is fine — review and update test scripts when the application's UI changes, treating them as living code requiring maintenance, not "write once" scripts.
Common Errors
Test fails intermittently with no clear pattern — consider adding more generous wait conditions/timeouts for elements to load, since flaky synthetic tests undermine trust in genuine failure alerts.
Continue Reading
- How to Set Up Uptime Monitoring for Your Website
- How to Set Up Effective Server Alerting (Without Alert Fatigue)
- How to Add Health Check Endpoints to Your Application
Browse more articles in Advanced Observability & Incident Management.