Monitoring

Site24x7 Synthetic Monitoring: Web Transaction and Browser Checks

29 Sep 2026 — 6 min read

Basic uptime checks tell you whether a URL responds with 200. Synthetic monitoring tells you whether your application actually works — can users log in, complete a checkout, search for content, and see results? These are different questions, and only synthetic monitoring answers the second one.

Site24x7 has three distinct types of synthetic monitoring: web page speed monitors, web transaction monitors, and real browser monitors. Here's how each works and when to use them.

Web Page Speed Monitor

A web page speed monitor loads a full page (HTML, CSS, JavaScript, images, fonts — all assets) and records the complete waterfall. This is the right tool when you want to track page performance over time and catch regressions in load time.

Setting Up a Web Page Speed Monitor

Go to Monitors > Website Monitoring > Add Monitor > Web Page Speed (Browser)
Enter the URL you want to measure
Select the browser: Chrome or Firefox (both headless)
Choose your probe locations — this check runs a full browser, so it's more resource-intensive than a ping check; pick 2-3 locations rather than 10
Set check frequency: every 10 or 30 minutes is typical (every 1 minute would be excessive for a full browser load)

The monitor runs a Lighthouse-style capture and records:

First Contentful Paint (FCP): when the first content appears
Time to Interactive (TTI): when the page is fully interactive
Total Page Load Time: complete load including all resources
Page Size: total bytes transferred
Number of Requests: total HTTP requests made by the page
Waterfall Chart: breakdown by resource, showing which assets are slow

Configuring Thresholds

Under Threshold and Availability, set:

Trouble threshold at a response time where users start noticing slowness (typically 3-5 seconds)
Critical threshold at clearly unacceptable performance (typically 8-10 seconds)

The monitor fires alerts when load time crosses these thresholds, not just when the page goes down. This catches performance degradations that uptime checks miss entirely.

Web Transaction Monitor (Selenium-Based)

Web transaction monitors simulate multi-step user flows using Selenium WebDriver. You record or write a script that clicks through your application, and Site24x7 runs that script from probe locations on a schedule.

This is where synthetic monitoring gets genuinely useful for QA teams — you can detect that the login flow is broken, the search returns no results, or the payment form rejects valid cards, all before a user reports it.

Recording a Web Transaction

Site24x7 provides a browser recorder extension (Chrome) that captures your click sequence and generates the Selenium script:

Install the Site24x7 Web Transaction Recorder Chrome extension
Go to Monitors > Website Monitoring > Add Monitor > Web Transaction (Browser)
Click Record — the extension opens a recording session
Walk through the user flow you want to monitor: navigate to the page, fill in fields, click buttons, verify results
Stop recording — the extension generates a Selenium IDE script
Review and adjust the script in the editor

Writing Web Transaction Scripts Manually

If the recorder doesn't handle your flow cleanly (SPAs with complex state, dynamic selectors, captchas), you can write the script directly in the Selenium IDE format within Site24x7's editor.

A basic login flow looks like:

open | https://app.yoursite.com/login |
type | id=email | testuser@example.com
type | id=password | testpassword
clickAndWait | id=submit-button |
assertTextPresent | Welcome, Test User |
assertLocation | https://app.yoursite.com/dashboard |

Key Selenium commands used in web transaction scripts:

open — navigate to URL
type — enter text in a field
click / clickAndWait — click an element; AndWait blocks until page load
assertTextPresent — verify text exists in the page body
assertElementPresent — verify a specific DOM element exists
waitForElementPresent — wait up to a timeout for an element to appear
storeText — capture text from an element into a variable for later assertions

Handling Dynamic Content

For pages where element IDs change between sessions (common in React/Vue apps), use CSS selectors or XPath instead:

click | css=button[data-testid='checkout-button'] |
waitForElementPresent | xpath=//div[@class='order-confirmation'] | 10000
assertTextPresent | Order confirmed |

The waitForElementPresent command with a timeout is essential for async UI updates — without it, assertions run before the DOM updates and fail spuriously.

Configuring Transaction Thresholds

Web transaction monitors measure total transaction time — the cumulative time to complete all steps. Set thresholds based on what's realistic for your flow:

A 5-step checkout flow taking more than 30 seconds is broken
A single login step taking more than 10 seconds is broken

Set step-level timeouts too: each individual step has a maximum wait time. If a step exceeds it, the transaction fails with a timeout error pointing to the exact step.

Real Browser Monitor

The real browser monitor is a step up from the Selenium-based transaction: it runs checks in a genuine browser instance (not headless) and captures screenshots, video recording, and a full HAR (HTTP Archive) of the network activity.

Use this for:

Visual regression detection (screenshots let you spot layout issues)
Debugging intermittent failures (video replay shows exactly what happened)
Performance audits with complete network waterfall

The setup is the same as web transactions but with additional capture options enabled. Note that real browser monitors cost more credits than standard web transactions.

SSL Certificate Monitoring

SSL certificate expiry is a silent killer — it causes complete outages when the certificate expires and browser clients refuse to connect. Site24x7 has dedicated SSL certificate monitoring.

Setting Up SSL Monitoring

Go to Monitors > Website Monitoring > Add Monitor > SSL/TLS Certificate
Enter your domain (without https:// — just the hostname)
Set alert thresholds: trigger a trouble alert 30 days before expiry, a critical alert 14 days before expiry

The monitor checks:

Days remaining until expiry
Certificate validity (is it actually trusted by root CAs?)
Certificate chain completeness (intermediate certificates present?)
Domain name match (does the cert cover the domain being checked?)

For sites with multiple domains or wildcard certificates, add a separate SSL monitor for each critical hostname. A wildcard cert covering *.example.com can still have chain issues on specific subdomains.

Handling Certificate Transparency

If you're monitoring a domain where the certificate is frequently rotated (e.g., Let's Encrypt with 90-day certs), set your warning threshold to 14 days and critical to 7 days — this avoids alert noise while still catching renewals that fail.

Maintenance Windows

Scheduled deployments, database migrations, and server reboots all cause monitoring alerts if you don't suppress them. Maintenance windows tell Site24x7 to silence alerts during a defined time window.

Configuring a Maintenance Window

Go to Admin > Maintenance (under Configuration Profiles)
Click Add Maintenance Window
Set the time window: specific date/time range or recurring (daily, weekly, monthly)
Select which monitors the window applies to — usually your entire production monitor group during a deployment window

During the maintenance window:

Monitors continue running (data collection doesn't stop)
Alerts are suppressed (no pages, no emails)
Downtime during the window is marked as "maintenance" in availability reports, not counted against SLA

For CI/CD pipelines that deploy multiple times per day, use the Site24x7 API to programmatically create and close maintenance windows as part of your deployment script:

# Open maintenance window via API
curl -X POST "https://www.site24x7.com/api/maintenance" \
  -H "Accept: application/json; version=2.0" \
  -H "Authorization: Zoho-oauthtoken YOUR_OAUTH_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "Deploy v2.1.0",
    "description": "Automated deployment",
    "maintenance_type": 1,
    "perform_monitoring": true,
    "start_date": "2026-06-05",
    "end_date": "2026-06-05",
    "start_time": "14:00",
    "end_time": "14:30",
    "monitors": ["12345678", "12345679"]
  }'

Threshold Alert Strategy

The mistake most teams make with synthetic monitoring is setting a single threshold and treating all violations as equal. A better model:

Trouble (Yellow): something is slower than expected but not yet user-impacting. Alert the on-call channel (Slack) but don't page anyone.

Critical (Red): something is broken or severely degraded. Page the on-call engineer immediately.

Transaction failure: a step in the web transaction raised an error (element not found, assertion failed, timeout). This is always critical — something is functionally broken.

Configure separate notification profiles for trouble vs. critical alerts. Trouble alerts going to PagerDuty at 3am cause alert fatigue and train engineers to ignore them.

What Synthetic Monitoring Doesn't Cover

Synthetic monitoring runs scripted flows with test accounts and static data. It won't catch:

Bugs that only appear with specific user data or state
Personalization failures (the user sees the wrong content)
Issues affecting real browser diversity (your script uses Chrome; Safari users might see something different)

Pair synthetic monitoring with real user monitoring (RUM) for production coverage and use synthetic for pre-production detection of functional regressions.

Running Synthetic Checks as Quality Gates

The most valuable use of web transaction monitors in a QA context: run them as smoke tests immediately after every deployment. If the login transaction fails after your deploy, that's your signal to roll back before users hit the failure.

Site24x7 supports on-demand monitor execution via API, which lets you trigger synthetic checks from your CI/CD pipeline and block the deployment if they fail. That integration turns monitoring from a passive observer into an active quality gate.