Synthetic Monitoring
Synthetic Monitoring enables proactive availability and performance testing by running scheduled tests from WhiteOwl probes deployed across your network. Unlike passive monitoring (NetFlow, SNMP), synthetic tests actively generate traffic to measure reachability, latency, packet loss, HTTP response times, and DNS resolution — giving you an end-user perspective of network and application performance from any location where a probe is deployed.
Overview
The Synthetic Monitoring page displays all configured tests in either a card view (grid) or list view, toggled via the view switcher in the toolbar. Each test card shows the test name, target, current metrics, test interval, last run time, and health status.
Toolbar Controls
| Control | Description |
|---|---|
| Filter | Filter tests by status: All, Active, Paused, or Failed. |
| Search | Search tests by name, target, or description. |
| View toggle | Switch between card (grid) and list (table) view. |
Test Card
Each test card displays at-a-glance metrics depending on the test type:
- ICMP Ping — Response time and packet loss percentage.
- HTTP/HTTPS — Response time and HTTP status code.
- DNS — Query time and response code (e.g.,
NOERROR).
Cards also show the test interval (e.g., "Every 1m"), the last run timestamp, and a health indicator.
Test Actions
Each test card has three action buttons:
| Action | Icon | Description |
|---|---|---|
| Pause / Resume | ⏸ | Pause a running test or resume a paused one. Paused tests stop executing but retain their configuration. |
| Settings | ⚙️ | Edit the test configuration — target, interval, thresholds, probe assignments, and notifications. |
| Delete | 🗑️ | Permanently remove the test and its historical results. |
Results
Click Results on any test card to view detailed historical data including time series charts of latency, packet loss, response time, and individual test result records.
Scheduler Status
The bottom of the page shows the Scheduler Status, confirming that the synthetic test scheduler is running and tests are being dispatched to probes on schedule.
Creating a Test
Click + Create Test to open the test builder. The builder adapts its fields based on the selected test type.
Common Fields
These fields apply to all test types:
| Field | Description |
|---|---|
| Test Type | The type of test: ICMP Ping, HTTP/HTTPS, or DNS. |
| Test Name | A descriptive name for the test (e.g., "Google DNS Check", "Curl to Ebay"). |
| Interval | How frequently the test runs: every 1 minute, 5 minutes, 10 minutes, 15 minutes, 30 minutes, or 60 minutes. |
| Target | The destination to test against. Format depends on test type — see each type below. |
| Run on Probes | Select one or more probes to execute this test. Tests can run from multiple probes simultaneously to measure performance from different network locations. |
| Description | Optional description of what the test monitors and why. |
Test Types
ICMP Ping
ICMP Ping tests measure network reachability and round-trip latency using ICMP echo requests. Optionally includes traceroute for path analysis.
Target format: IP address or hostname (e.g., 8.8.8.8, google.com).
What it measures:
| Metric | Description |
|---|---|
| Latency (min / avg / max) | Round-trip time in milliseconds — minimum, average, and maximum across the configured ping count. |
| Packet Loss | Percentage of ICMP echo requests that received no reply. |
| Status | Whether the target is reachable (up) or unreachable (down). |
| Traceroute | Hop-by-hop path to the target with per-hop latency (when traceroute is enabled). |
Advanced options:
| Field | Description | Default |
|---|---|---|
| Ping Count | Number of ICMP echo requests per test execution. More pings provide more accurate latency statistics. | 4 |
| Ping Timeout (sec) | Maximum time to wait for a response per ping. | 10 |
| Max Hops | Maximum number of hops for traceroute. | 30 |
Use cases: WAN link availability, inter-site latency measurement, packet loss detection, VPN tunnel health, and network path tracking via traceroute.
HTTP/HTTPS
HTTP tests monitor web application availability and performance by making full HTTP or HTTPS requests and measuring response characteristics.
Target format: Full URL including protocol (e.g., https://api.example.com/health, https://www.ebay.com).
What it measures:
| Metric | Description |
|---|---|
| Response Time | Total time from request initiation to complete response (milliseconds). Includes DNS resolution, TCP connect, TLS handshake, and content transfer. |
| Status Code | The HTTP response status code (e.g., 200, 301, 404, 503). |
| SSL/TLS Validity | Whether the TLS certificate is valid and trusted (for HTTPS targets). |
Advanced options:
| Field | Description | Default |
|---|---|---|
| Method | HTTP request method: GET, POST, PUT, DELETE, HEAD. | GET |
| Timeout (sec) | Maximum time to wait for a complete response. | 30 |
| Expected Status | The HTTP status code that indicates success. Any other code is treated as a failure. | 200 |
| Verify SSL Certificate | Whether to validate the TLS certificate chain. Disable for self-signed or internal certificates. | ✅ Enabled |
Use cases: Website and API availability, response time monitoring, SSL certificate health, error detection before users report, and performance comparison across network locations.
DNS
DNS tests verify domain name resolution by querying a DNS server and measuring query time, response accuracy, and resolution health.
Target format: Domain name to resolve (e.g., google.com, internal.corp.local).
What it measures:
| Metric | Description |
|---|---|
| Query Time | Time to resolve the DNS query (milliseconds). |
| Response Code | The DNS response code (e.g., NOERROR, NXDOMAIN, SERVFAIL). |
| Answers | The resolved records returned by the DNS server. |
| Match Status | Whether the resolved answer matches the expected value (if configured). |
DNS-specific fields (shown in the builder):
| Field | Description | Default |
|---|---|---|
| Record Type | The DNS record type to query: A, AAAA, CNAME, MX, NS, TXT, PTR, SOA. | A |
| DNS Server (optional) | The DNS server to query (e.g., 8.8.8.8). Leave blank to use the system default resolver. | System default |
Advanced options:
| Field | Description | Default |
|---|---|---|
| Timeout (sec) | Maximum time to wait for a DNS response. | 5 |
| Expected Value (optional) | An expected answer to validate against (e.g., a specific IP address like 192.168.1.1). If set, the test reports whether the actual answer matches. | — |
Use cases: DNS infrastructure health, propagation verification after changes, DNS hijacking detection, resolver performance comparison across sites, and validating that critical domains resolve to expected IPs.
Multi-Probe Execution
Tests can be assigned to run on multiple probes simultaneously. This enables:
- Multi-location testing — Measure latency and availability from different offices, data centers, or cloud regions to the same target. Compare results to identify location-specific issues.
- Redundant monitoring — Ensure that a test failure is confirmed from multiple vantage points before alerting, reducing false positives from single-probe network issues.
- Path diversity analysis — Run traceroute from multiple probes to see how traffic takes different paths to the same destination.
When viewing results for a multi-probe test, data is broken down per probe so you can compare performance across locations.
Alert Thresholds
Each synthetic test can have built-in alerting configured under Advanced Options & Notifications.
Check Enable alerts for this test to activate threshold-based alerting. When enabled, the test results feed into WhiteOwl's alert engine and alerts appear on the Alert Management page alongside SNMP, Flow, and AI alerts.
Available thresholds vary by test type:
ICMP Ping Thresholds
| Threshold | Description |
|---|---|
| Latency threshold (ms) | Alert when average round-trip time exceeds this value. |
| Packet loss threshold (%) | Alert when packet loss percentage exceeds this value. |
| Hops threshold | Alert when traceroute hop count exceeds this value (may indicate routing changes). |
HTTP Thresholds
| Threshold | Description |
|---|---|
| Response time threshold (ms) | Alert when total response time exceeds this value. |
| Expected status code | Alert when the response status code does not match the expected value. |
| SSL certificate expiry | Alert when the SSL certificate is approaching expiration. |
DNS Thresholds
| Threshold | Description |
|---|---|
| Query time threshold (ms) | Alert when DNS resolution time exceeds this value. |
| Expected value mismatch | Alert when the resolved answer does not match the expected value. |
| Response code | Alert on non-NOERROR response codes. |
Notification Channels
Synthetic test alerts support the same notification channels available in Alert Management. Click + Add Channel under Notification Channels in the Advanced Options section to add one or more channels:
| Channel | Description |
|---|---|
| Webhook | HTTP POST to a custom endpoint with JSON payload containing test name, target, current metrics, threshold, and failure details. |
| Slack | Send formatted alert messages to a Slack channel via incoming webhook. Configure the webhook URL, channel, bot name, and emoji. |
| Syslog | Forward alert notifications as syslog messages to a remote syslog server. Configure server, port, protocol (UDP/TCP), and facility. |
Multiple channels can be configured on a single test — for example, sending to both a Slack channel for team visibility and a webhook for PagerDuty integration.
Synthetic test alerts are fully integrated with Alert Management. Once alert thresholds are enabled on a test, fired alerts appear in the Active Alerts tab, follow the same lifecycle (firing → acknowledged → resolved), and are recorded in Alert History. You can also create additional alert rules targeting synthetic test data sources (Synthetic Ping Tests, Synthetic HTTP Tests, Synthetic DNS Tests) from the Alert Management page for more complex conditions like baseline deviation detection.
Data Retention
Synthetic test results are stored in ClickHouse with a 90-day retention policy (TTL). Results older than 90 days are automatically purged. This applies to all test types — ping, HTTP, DNS, and traceroute hop data.