Catchpoint Synthetic Monitoring: API, Browser, and Network Tests Explained

Synthetic monitoring runs scripted tests against your applications and infrastructure on a continuous schedule — before real users encounter problems. Catchpoint's synthetic monitoring platform offers one of the most comprehensive test type libraries in the industry, running from over 2,500 nodes across backbone networks, last-mile ISPs, cloud providers, and wireless carriers.

This guide breaks down every major synthetic test type in Catchpoint, when to use each, and how to configure them effectively.

Why Synthetic Monitoring Matters

Real User Monitoring (RUM) tells you what happened after users experienced a problem. Synthetic monitoring tells you about problems before they affect users. The combination is essential:

• Synthetic: Scheduled tests run 24/7 from global nodes, catching issues in minutes
• RUM: Captures actual user sessions, revealing real-world performance distribution

For SLA enforcement, synthetic is usually the definitive measure — you can run the exact test that corresponds to your SLA metric on a predictable schedule.

Test Types in Catchpoint

1. Web Tests (Browser)

Web tests load a full page in a headless Chromium browser and capture complete performance metrics including Core Web Vitals.

What you get:

• Full page load waterfall
• Time to First Byte (TTFB)
• First Contentful Paint (FCP)
• Largest Contentful Paint (LCP)
• Cumulative Layout Shift (CLS)
• Total page weight and resource count
• JavaScript errors

Configuration:

Test Type: Web
URL: https://yoursite.com/product/123
Frequency: Every 5 minutes
Browser: Chrome (latest)
Viewport: 1920x1080 (desktop), 375x812 (mobile)
Connection: Native / Throttled 4G

When to use:

• Homepage and key landing pages
• Any page where Web Core Vitals directly affect SEO ranking
• Pages with heavy JavaScript rendering
• E-commerce product and category pages

Script mode: For pages requiring authentication or complex interactions, switch to script mode and write Catchpoint's JavaScript-based browser automation:

// catchpoint browser script example
step("Navigate to login", function() {
  page.navigateTo("https://yourapp.com/login");
});

step("Enter credentials", function() {
  page.fillTextField("#email", "test@example.com");
  page.fillTextField("#password", "testpass123");
  page.click("#submit");
});

step("Verify dashboard loaded", function() {
  page.waitForElement("#dashboard-header", 5000);
  assert.equal(page.getTitle(), "Dashboard - YourApp");
});

2. Transaction Tests

Transaction tests simulate multi-step user journeys in a browser, measuring each step individually. Unlike basic web tests, they validate functional behavior in addition to performance.

What you get:

• Per-step response times and availability
• Screenshot at each step
• Full waterfall per step
• Error detection with screenshots on failure

Use cases:

• Login → dashboard flow
• Search → product detail → add to cart → checkout
• Form submission and confirmation
• Any critical user journey

Configuration:

Transaction tests use the same scripting API as browser web tests but are structured as ordered steps:

step("Load homepage", function() {
  page.navigateTo("https://yourstore.com");
  page.waitForElement(".hero-banner", 3000);
});

step("Search for product", function() {
  page.fillTextField("#search-box", "running shoes");
  page.click("#search-submit");
  page.waitForElement(".search-results", 5000);
});

step("Select first result", function() {
  page.click(".product-card:first-child a");
  page.waitForElement(".product-detail", 3000);
});

step("Add to cart", function() {
  page.click("#add-to-cart");
  page.waitForElement(".cart-count", 2000);
  assert.equal(page.getText(".cart-count"), "1");
});

Each step generates independent metrics, so you know exactly which part of the flow is slow.

3. API Tests

API tests send HTTP/HTTPS requests and validate responses without a browser. They run faster and cheaper than browser tests, making them suitable for high-frequency monitoring.

What you get:

• HTTP status code
• Response time (breakdown by DNS, connect, SSL, TTFB, download)
• Response body validation
• Response header validation
• Certificate expiry monitoring

Configuration:

Method: GET / POST / PUT / DELETE
URL: https://api.yoursite.com/v2/users/me
Headers:
  Authorization: Bearer {{token}}
  Content-Type: application/json
Body (for POST/PUT):
  {"key": "value"}
Expected Status Code: 200
Expected Body Contains: "userId"
Frequency: Every 1 minute

Assertion types:

When to use:

• Health check endpoints
• Critical API endpoints
• Authentication endpoints
• Payment processing webhooks
• Third-party API dependencies

4. DNS Tests

DNS tests query nameservers and validate resolution times, returned records, and propagation consistency.

What you get:

• DNS resolution time by node
• Returned IP addresses and record values
• Comparison across resolver nodes (detecting propagation issues)
• DNSSEC validation

Configuration:

Record Type: A / AAAA / CNAME / MX / TXT / NS
Hostname: yoursite.com
Expected Response: 1.2.3.4
Resolver: Default (node's resolver) or Specify custom

When critical:

• After DNS record changes (verify propagation)
• If you're running your own nameservers
• For detecting DNS hijacking or poisoning
• Monitoring TTL behavior

A DNS test running from 20 global nodes can detect propagation gaps where some users see old records while others see new ones — a scenario invisible to server-side monitoring.

5. Ping Tests (ICMP)

Ping tests send ICMP echo requests and measure round-trip time and packet loss.

What you get:

• Round-trip time (RTT)
• Packet loss percentage
• Jitter

Limitations: Many firewalls block ICMP. A failed ping test doesn't mean your HTTP service is down — verify with an API test before alerting.

When useful:

• Infrastructure-level availability (not application availability)
• Network path baseline measurement
• Comparing latency across network paths

6. Traceroute Tests

Traceroute tests map the network path between a Catchpoint node and your server, identifying every hop along the route.

What you get:

• Full hop-by-hop path visualization
• Per-hop latency
• Path change detection
• Autonomous System (AS) path analysis

Key use case: When you see high latency from specific regions, traceroute tests help diagnose whether the issue is in your infrastructure, your CDN, a specific ISP, or an upstream transit provider.

From: Catchpoint New York backbone node
To: 104.21.55.123 (your server IP)

Hop 1: 1.2ms  — Local router
Hop 2: 3.4ms  — ISP gateway
Hop 3: 8.1ms  — Tier-1 transit
Hop 4: 45.2ms — Transcontinental link
Hop 5: 51.3ms — CDN edge node
Hop 6: 52.1ms — Your server

If hop 4 shows unexpected latency increases, you have a transit routing issue.

7. Ping with Traceroute (MTR)

Combines ongoing ping measurements with traceroute path visualization. Runs continuously for a configured duration and shows packet loss at each hop over time.

Useful for detecting intermittent network issues that point-in-time traceroutes miss.

8. FTP/SFTP Tests

Tests connectivity and transfer performance to FTP/SFTP servers:

• Connection time
• Login authentication
• File upload/download speeds
• Directory listing

Mostly used in legacy enterprise environments with file-based integrations.

9. Streaming Tests

Validates video and audio stream availability and quality metrics:

• Stream availability
• Buffering events
• Bitrate measurement
• Start time

Relevant for media companies or applications with embedded video.

Choosing the Right Test Type

Configuring Test Frequency

Frequency depends on the criticality of the service and your alerting requirements:

Higher frequency means faster detection but consumes more of your test budget. Start conservatively and increase frequency for tests that have caught real incidents.

Alert Configuration Best Practices

Avoid Single-Check Alerts

Never alert on a single failed check. Network blips, DNS timeouts, and momentary congestion cause false positives. Configure alerts to trigger after:

• 2 consecutive failures from any node
• Failures from 2+ different nodes simultaneously

Alert when: 2 of last 3 checks fail from the same node
OR
Alert when: Any 2 nodes fail simultaneously

Threshold Calibration

After 2 weeks of data, review your p95 response times by node. Set your warning threshold at p95 and critical threshold at 2x p95. This ensures alerts reflect real degradation rather than normal variability.

Alert Routing

Route alerts based on severity and team:

Interpreting Synthetic Results

Waterfall Analysis

The waterfall is your primary debugging tool. For a slow page load, identify which phase is consuming time:

Node Comparison

When a performance issue affects only certain regions:

• All nodes slow: Server-side issue or upstream network problem
• One region slow: CDN miss, regional routing issue
• Mobile nodes slow: Connection throttling, resource size
• Last-mile nodes slow: ISP congestion or peering issue

Trend Analysis

Short-term spikes are often network noise. Focus on:

• Upward trends over days/weeks (gradual degradation)
• Step changes that correlate with deployments
• Time-of-day patterns (indicating load-related issues)

Integrating Synthetic Results with Deployments

The most valuable use of synthetic monitoring is correlating performance changes with code deployments. When your CI/CD pipeline deploys:

1. Tag the deploy in Catchpoint via webhook or API
2. Review performance charts for the 30 minutes post-deploy
3. Compare to baseline from the same time window previous week
4. Fail the deploy if response time degrades by more than 20%

This turns synthetic monitoring from a reactive alert system into a proactive quality gate.

Functional Testing vs. Synthetic Monitoring

Catchpoint's transaction tests validate that user flows complete — but they don't assert application-level behavior in depth. For thorough functional verification:

• Did the search return relevant results?
• Did the price calculation apply the discount correctly?
• Did the email notification actually send?

These require dedicated functional test automation. Tools like HelpMeTest complement synthetic monitoring by running plain-English behavior tests against your application, giving you coverage of both performance and correctness.

Combined, synthetic monitoring and functional testing provide complete visibility into application quality before and after every deployment.