Web-Layer Tests

Web layer tests are designed to monitor and evaluate the performance, availability, and user experience of web-based services, such as websites, web applications, and APIs. These tests focus on the application layer and emulate user interactions or browser behaviors to provide insights into how web services perform from various global or internal vantage points. Web layer tests assess the end-user experience of web services by measuring availability, response times, and performance. They help organizations monitor critical web applications, troubleshoot issues, and optimize performance.

Web Layer tests include:

  • HTTP Server Tests: Monitor single HTTP/HTTPS requests to an endpoint.

  • Page Load Tests: Perform browser loading of a web page and its resources.

  • Transaction Tests: Perform multi-step user interactions or API sequences.

  • FTP Server Tests: Monitor file transfer operations on FTP, FTPS, or SFTP servers.

HTTP Server Test

For more information about HTTP server tests, see HTTP Server Tests.

API Test

For more information about API tests, see API Tests.

Page Load Test

Page load tests are designed to monitor the performance and availability of web pages by loading a page and its associated resources (e.g., images, scripts, CSS) in a browser. These tests collect metrics to provide insights into user experience and web performance. Page load tests use te-chromium, a browser based upon the Chromium browser codebase. A complete explanation is available here: Navigating Waterfall Charts for Page Load and Transaction Tests.

Instant page load tests provide a screenshot upon test completion, while scheduled page load tests only provide screenshots when errors are recorded. A list of permitted content types is available in Permitted Content Types.

Use Cases for Page Load Tests

Page load tests are critical for organizations aiming to optimize web page performance, ensure user satisfaction, and troubleshoot issues affecting page loading. The primary use cases include:

  • Monitoring web page performance to ensure web pages load quickly and reliably to provide a seamless user experience

  • Troubleshooting slow page loads to diagnose why users experience delays when loading web pages

  • Evaluating CDN performance in delivering web page resources globally.

  • Monitoring the impact of third-party resources (e.g., ads, analytics scripts) on page load performance.

  • Identifying misconfigurations or security issues affecting page loads, such as SSL certificate problems.

  • Pre-Deployment validation to test web pages in staging environments before public release

Page Load Test Metrics

Page load tests collect metrics that capture the entire process of loading a web page, from initiating the request to rendering all resources.

  • Page Load Time (ms): The total time to fully load the web page, from initiating the request to completing the rendering of all resources.

  • Completion (%): The percentage of Page Load Test executions that successfully complete without critical errors.

  • Timeouts (count): The number of test executions that fail due to timeouts, where the page or a resource fails to load within the configured test timeout period.

  • Errors (count): The number of test executions encountering errors, such as HTTP status codes (e.g., 404 Not Found, 500 Internal Server Error), DNS failures, or script errors, excluding timeouts.

  • Chromium Version: The version of the Chromium browser engine used by the ThousandEyes agent to execute the Page Load Test, specified as a version number.

  • Page Size (bytes):The total size of all resources (e.g., HTML, images, scripts, CSS) loaded during the Page Load Test, measured in bytes, including headers and compressed content.

  • Components (count): The number of individual resources (e.g., HTML files, images, JavaScript files, CSS files) requested and loaded during the Page Load Test.

  • DOM Load Time (ms): The time from initiating the request to when the Document Object Model (DOM) is fully parsed and the DOMContentLoaded event fires, excluding the loading of sub-resources like images or scripts.

Page Load Test Views

  • Timeline (Page Load Layer)

  • Map

  • Table

  • Waterfall: A detailed breakdown of the load sequence, showing the timing and status of each resource.

Below is a page load test targeting Google:

For more information, see Using the Page Load View.

Other Included Tests

  • HTTP server test

  • Agent-to-server test

  • BGP test

Manually Configuring Page Load Tests

To configure a Page Load test:

  1. In the ThousandEyes platform, navigate to Network & Synthetics > Test Settings.

  2. Click the + button in the upper right corner of the screen.

  3. Under the Web & API Tests section, select the card titled Website Performance.

  4. The configuration page is divided into the following sections: Basic Settings, Network and Security Settings, HTTP Communication and Performance, Page Load Performance and Browser Settings, and Additional Settings.

Page Load Test Basic Settings

Setting
Description

URL

The full URL of the web page to load. The test uses a real browser to load this URL and all its dependent components, such as CSS, JavaScript, images, to measure the complete user experience.

How often the test runs

The frequency at which the test runs. Options are 1, 2, 5, 10, 15, 30, or 60 minutes. More frequent intervals are recommended for business-critical services.

Where the test runs from

Select one or more ThousandEyes Cloud Agents or Enterprise Agents (with browser capabilities) to run the test from. For help, see Using the Agent Selector.

Alerts

Enable or disable alerts for this test and assign one or more alert rules. The dropdown shows the number of selected rules out of the total available.

Labels

Assign agent labels to this test for filtering and organization. The dropdown shows the number of selected labels out of the total available.

Test Name

A name for the test. The name auto-populates from the URL's domain but can be manually edited. The maximum length is 255 characters.

Page Load Test Network and Security Settings

By default, a Page Load test focuses on browser-level metrics. To gain deeper insight and correlate web performance with the underlying network path, you can enable network measurements.

Setting
Description

Perform Network Measurements

When this toggle is enabled, the test will run a concurrent agent-to-server network test to the page's host domain. This captures essential network-layer metrics like packet loss, latency, and jitter, and allows you to visualize the network path and BGP routing data. Enabling this option is highly recommended for comprehensive root cause analysis, as it helps you determine if a slow page load is caused by application issues or by problems on the network path.

Define which data to collect

Select the types of network data to collect during the test.

  • Bandwidth: Measures available network bandwidth by sending a series of packet streams ("packet trains") to the server. The test is iterative: it starts with a small stream (100 packets) and may increase in size (up to 2000 packets) until a stable throughput measurement is calculated based on packet delay analysis. > Note: This option does not increase test unit consumption but does generate additional traffic, which may impact performance on resource-constrained networks. It is recommended to keep this option disabled for tests using agents on routers or switches.

  • Maximum Transmission Unit (MTU): Determines the Maximum Transmission Unit (MTU) size along the network path to identify issues related to packet fragmentation.

  • Collect BGP data: Correlates network data with BGP routing data. Tests with IPv4 targets use IPv4 BGP monitors, and tests with IPv6 targets use IPv6 BGP monitors.

Protocol

The transport layer protocol (TCP or ICMP) used for the accompanying network measurements (loss, latency, jitter).

Path trace mode

When In Session is selected, the path trace is performed within an established TCP session. > Note: This mode is designed for environments where stateful firewalls (e.g., Palo Alto Networks, Juniper SRX) might otherwise block standard path trace packets.

Probing mode

Defines the TCP probing method used for network measurements. This setting is available only when the Protocol is set to TCP.

  • Prefer SACK: (Default) Uses a single TCP connection with Selective Acknowledgement (SACK) for efficient, low-overhead measurements.

  • Force SYN: Sends a stream of up to 50 SYN packets from unique source ports. Use this method if SACK is not supported or is blocked in the network path.

Transmission rate

Controls the rate at which packets are sent for network measurements. Use this to simulate network load or validate Quality of Service (QoS) policies.

Number of path traces

Sets the number of path traces (3 to 10) performed in each test round. Increasing the number helps discover and visualize multiple or asymmetric network paths.

IPv6 Policy

Determines how the agent resolves the target's domain name in dual-stack (IPv4/IPv6) environments.

  • Agent's Policy: Uses the agent's local DNS resolution policy.

  • IPv4 only: Forces DNS resolution to IPv4 addresses.

  • Prefer IPv6: Attempts to resolve to an IPv6 address first, with a fallback to IPv4.

  • Force IPv6: Resolves only to IPv6 addresses.

Proxy settings

Defines how the test connects to the target through a proxy server.

  • Direct: Connects directly to the target, bypassing any proxy.

  • Agent's Policy: Uses the proxy configuration defined on the Enterprise Agent.

  • Specific Proxy Config: Uses a specific proxy server defined in the test settings.

Perform network measurements to the proxy

When enabled, network measurements (loss, latency) are performed to the proxy server instead of the final target. Use this to isolate performance issues related to the proxy itself.

TLS SSL version

Selects the specific TLS/SSL protocol version for the HTTPS connection. Auto (Default) negotiates the highest version supported by both the agent and the server. Older versions are available for testing legacy system compatibility.

Verify SSL Certificate

When enabled, the agent validates the server's SSL/TLS certificate against its trust store. This ensures the certificate is authentic, valid, and not expired. Disable this only for testing environments with self-signed or invalid certificates.

Add client certificate

Enables mutual TLS (mTLS) authentication by providing a client-side certificate. The certificate must be in PEM format. Use this to test systems that require client certificate authentication for access. For more information about adding a client certificate, see HTTP Server Tests: Adding a Client Certificate to HTTP Server Test Settings

Allow unsafe legacy renegotiation

Allows TLS renegotiation with older servers that do not support the secure renegotiation extension (RFC 5746). Enable this only for compatibility testing with legacy systems.

Page Load Test HTTP Communication and Performance Settings

Setting
Description

Timeout

Defines the maximum time (default 5s, max 60s) the agent will wait for a response from the server. Adjust this value based on expected response times to avoid premature test failures for slow services or large downloads.

Target response time

Sets a performance threshold for the server's response time. If the actual response time exceeds this value, the test round is flagged with a performance warning. This can be used to trigger alerts.

Enable distributed tracing

When enabled, adds an HTTP trace context header to the request. This allows the request to be tracked across multiple backend services in a distributed system, helping to pinpoint performance bottlenecks in complex applications.

Desired status code

Verifies that the server returns a specific HTTP status code or a code within a range (e.g., 2xx or 3xx). The test fails if the response code does not match the desired value.

Verify content

Verifies that the server's response body contains (or does not contain) specific text. This is useful for detecting errors and validating that the correct content was served.

Limit download size

Sets a maximum size for the downloaded response body. This conserves bandwidth and focuses the test on availability and response time metrics rather than full content download.

HTTP version

Selects the preferred HTTP protocol version for the test.

  • Prefer HTTP/2: (Default) Uses HTTP/2 if the server supports it, falling back to HTTP/1.1 if not.

  • HTTP/1.1 Only: Forces the test to use only the HTTP/1.1 protocol.

Request method

The HTTP method used for the request.

  • GET: (Default) Retrieves data from the server.

  • POST: Submits data to be processed by the server.

Follow redirects

When enabled, the test will follow HTTP 3xx redirect responses to the final destination URL. Disable this to test the initial response of a specific URL without following the redirect chain.

User agent

Sets the User-Agent string in the HTTP request header. Use the default, select a predefined agent from the list, or provide a custom string to simulate a specific client or to tag test traffic.

Override DNS

Maps the test's target hostname to a specific IP address, bypassing public DNS resolution. This is useful for testing pre-production environments or specific servers behind a load balancer.

Custom HTTP headers

Adds custom headers to HTTP requests made during the test. Headers can be applied to:

  • Root request: The initial request to the target URL only.

  • Specific domain: Requests to a specified domain.

  • All domains: All requests made during the test, including those for embedded objects.

Scheme

Selects the HTTP authentication method to use when accessing a protected resource.

  • Basic: Uses a simple username and password.

  • NTLM: A challenge-response protocol used for integrated authentication in Windows environments, often for services like IIS or SharePoint.

  • Kerberos: Uses network credentials for single sign-on (SSO) in enterprise environments.

Page Load Test Page Load Performance and Browser Settings

Setting
Description

Timeout

Defines the maximum time (default 10s) the browser will wait for the page load event to complete before the test fails.

Target Response Time

Sets a performance threshold (default 6s) for the Page Load Time metric. If the actual load time exceeds this value, the test round is flagged with a performance warning.

Chromium Version

Selects the version of the Chromium browser used by the agent.

  • Default: Uses the standard, stable version of Chromium.

  • Newer when available: Automatically uses the latest available Chromium version, which may include new features but could affect performance consistency.

> Note: The current default Chromium version is 132.

Screenshot

When enabled, captures a screenshot of the fully rendered web page at the end of the test.

Preferred Language

Sets the Accept-Language header and browser locale. Some websites use this to serve localized content. Default is English (US).

Microphone and Camera

Controls whether the browser grants or denies permission for the web page to access the system's microphone and camera.

Geolocation

Controls whether the browser grants or denies permission for the web page to access the Geolocation API.

Page Loading Strategy

Determines when the browser considers the page navigation complete.

  • Normal: (Default) Waits for the full page load, including all sub-resources like images and scripts.

  • Eager: Waits only for the initial HTML document to be downloaded and parsed (DOMContentLoaded event).

  • None: Returns immediately after the initial HTML is received.

Device Emulation

Simulates the viewport of different device types (Desktop, Laptop, Phone, Tablet) by setting a custom screen resolution.

HTTP Headers in Waterfall

Controls whether the full request and response headers for each object are displayed in the test results' waterfall view.

Exclude Domains / Object URLs

Prevents the browser from loading objects from specified domains or URLs. Use this to isolate the performance of your own application by excluding third-party scripts, ads, or trackers. You can use wildcards or specific URLs for matching.

Page Load Test Additional Settings

Setting
Description

Description

An optional, user-defined description for the test. Use this field to add context, change history, or other notes for fellow users.

Alert suppression window

Temporarily disables all alerts for this test for a defined period. Use this feature for planned maintenance windows to prevent false-positive alerts.

Transaction Test

Transaction tests are web layer tests designed to emulate multi-step user interactions in a browser or API sequences on web services, mimicking real user journeys such as logging into a website, completing a purchase, or executing a series of API calls. Unlike HTTP server tests, which focus on single requests, or page load tests, which measure a single page rendering, transaction tests interact dynamically with web pages or APIs, providing deeper insights into user experience and application functionality. Transaction tests use the Selenium WebDriver engine. Test scripts are created using JavaScript, from the ThousandEyes Recorder IDE or within the test settings. You can set screenshots and markers at different points within the script to identify important points within the transaction workflow.

For more information, see Transaction Tests.

Use Cases for Transaction Tests

Transaction tests are ideal for scenarios requiring validation of multi-step interactive web workflows. Key use cases include:

  • Emulating user actions like logging in, searching, or checking out to ensure critical workflows are functional and fast

  • Testing sequences of API calls (e.g., authentication, data retrieval) to ensure reliability and performance

  • Diagnosing why users encounter errors or delays in web applications

Transaction Test Metrics

Transaction tests collect metrics to assess the performance and success of scripted user journeys or API sequences.

  • Transaction Time (ms): The total time to complete the entire scripted transaction, from the start of the first action to the final step’s completion, measured in milliseconds.

  • Completion (%): The percentage of Transaction Test executions that successfully complete all scripted steps without critical errors.

  • Timeouts (count): The number of test executions that fail due to timeouts, where a scripted step exceeds the configured timeout period.

  • Assert Errors (count): The number of test executions failing due to assertion failures, where a scripted validation check (e.g., check(response.status === 200) or text presence on a page) does not meet the expected condition.

  • Page Errors (count): The number of test executions encountering page-level errors, such as HTTP status codes (e.g., 404 Not Found, 500 Internal Server Error) or browser errors (e.g., JavaScript exceptions) during page loads within the transaction.

  • Other Errors (count): The number of test executions failing due to miscellaneous errors not classified as timeouts, assert errors, or page errors, such as script execution errors (e.g., syntax errors in the transaction script), network connectivity issues, or browser-specific issues.

  • Markers (count): The number of custom-defined checkpoints (markers) in the transaction script that are successfully reached during test execution, used to track progress through specific steps or events (e.g., "Login Completed", "Form Submitted").

  • Average Marker Timing (ms): The average time taken to reach each custom-defined marker in the transaction script across test executions, measured in milliseconds, reflecting the duration of individual steps or events.

  • Screenshots (count): The number of screenshots captured during test execution, triggered at specific points in the transaction script (e.g., after a page load, form submission, or error) to visually document the application’s state.

Transaction Test Views

  • Timeline (Transaction Layer)

  • Map

  • Table

  • Waterfall: A detailed breakdown of the load sequence, showing the timing and status of each resource.

The transaction test below performs a login and a search.

Other Included Tests

  • HTTP server test

  • Agent-to-server test

  • BGP test

Manually Configuring Transaction Tests

To configure a Transaction test:

  1. In the ThousandEyes platform, navigate to Network & Synthetics > Test Settings.

  2. Click the + button in the upper right corner of the screen.

  3. Under the Web & API Tests section, select the card titled Website Transaction.

  4. The configuration page is divided into the following sections: Basic Settings, Network and Security Settings, HTTP Communication and Performance, Transaction Performance and Browser Settings, and Additional Settings.

  5. Click Next to provide a script for your transaction test.

For additional guidance on scripting for transaction tests, see:

Transaction Test Basic Settings

Setting
Description

URL

The URL of the first page in the user journey. This serves as the starting point for the transaction script that simulates user actions like clicking, typing, and navigating.

How often the test runs

The frequency at which the test runs. Options are 1, 2, 5, 10, 15, 30, or 60 minutes. 5 or 10 minutes is typically preferred due to the comprehensive nature of simulating a multi-step user transaction.

Where the test runs from

Select one or more ThousandEyes Cloud Agents or Enterprise Agents (with browser capabilities) to run the test from. For help, see Using the Agent Selector.

Alerts

Enable or disable alerts for this test and assign one or more alert rules. The dropdown shows the number of selected rules out of the total available.

Labels

Assign agent labels to this test for filtering and organization. The dropdown shows the number of selected labels out of the a vailable.

Test Name

A name for the test. While this can auto-populate from the starting URL, it is highly recommended to use a descriptive name that reflects the user journey being tested, for example, "User Login and Checkout".

Transaction Test Network and Security Settings

By default, a Transaction test focuses on browser-level metrics that measure the performance of a scripted user journey. To gain deeper insight and correlate the performance of each step with the underlying network path, you can enable network measurements.

Setting
Description

Perform Network Measurements

When this toggle is enabled, the test will run a concurrent agent-to-server network test for each page view within the transaction script. This captures essential network-layer metrics like packet loss, latency, and jitter for every navigation, allowing you to visualize the network path and BGP routing data for each step of the user journey. Enabling this option is highly recommended for comprehensive root cause analysis, as it helps you determine if transaction failures or performance degradation are caused by application issues or by problems on the underlying network path.

Define which data to collect

Select the types of network data to collect during the test.

  • Bandwidth: Measures available network bandwidth by sending a series of packet streams ("packet trains") to the server. The test is iterative: it starts with a small stream (100 packets) and may increase in size (up to 2000 packets) until a stable throughput measurement is calculated based on packet delay analysis. > Note: This option does not increase test unit consumption but does generate additional traffic, which may impact performance on resource-constrained networks. It is recommended to keep this option disabled for tests using agents on routers or switches.

  • Maximum Transmission Unit (MTU): Determines the Maximum Transmission Unit (MTU) size along the network path to identify issues related to packet fragmentation.

  • Collect BGP data: Correlates network data with BGP routing data. Tests with IPv4 targets use IPv4 BGP monitors, and tests with IPv6 targets use IPv6 BGP monitors.

Protocol

The transport layer protocol (TCP or ICMP) used for the accompanying network measurements (loss, latency, jitter).

Path trace mode

When In Session is selected, the path trace is performed within an established TCP session. > Note: This mode is designed for environments where stateful firewalls (e.g., Palo Alto Networks, Juniper SRX) might otherwise block standard path trace packets.

Probing mode

Defines the TCP probing method used for network measurements. This setting is available only when the Protocol is set to TCP.

  • Prefer SACK: (Default) Uses a single TCP connection with Selective Acknowledgement (SACK) for efficient, low-overhead measurements.

  • Force SYN: Sends a stream of up to 50 SYN packets from unique source ports. Use this method if SACK is not supported or is blocked in the network path.

Transmission rate

Controls the rate at which packets are sent for network measurements. Use this to simulate network load or validate Quality of Service (QoS) policies.

Number of path traces

Sets the number of path traces (3 to 10) performed for each page navigation in the transaction. Increasing the number helps discover and visualize multiple or asymmetric network paths.

IPv6 Policy

Determines how the agent resolves domain names in dual-stack (IPv4/IPv6) environments for all domains accessed during the transaction.

  • Agent's Policy: Uses the agent's local DNS resolution policy.

  • IPv4 only: Forces DNS resolution to IPv4 addresses.

  • Prefer IPv6: Attempts to resolve to an IPv6 address first, with a fallback to IPv4.

  • Force IPv6: Resolves only to IPv6 addresses.

Proxy settings

Defines how the test connects to target domains through a proxy server for the entire transaction.

  • Direct: Connects directly to the target, bypassing any proxy.

  • Agent's Policy: Uses the proxy configuration defined on the Enterprise Agent.

  • Specific Proxy Config: Uses a specific proxy server defined in the test settings.

Perform network measurements to the proxy

When enabled, network measurements (loss, latency) are performed to the proxy server instead of the final target for each page navigation. Use this to isolate performance issues related to the proxy itself.

TLS SSL version

Selects the specific TLS/SSL protocol version for all HTTPS connections made during the transaction. Auto (Default) negotiates the highest version supported.

Verify SSL Certificate

When enabled, the agent validates the SSL/TLS certificate for every HTTPS connection made during the transaction. Disable this only for testing environments with self-signed or invalid certificates.

Add client certificate

Enables mutual TLS (mTLS) authentication by providing a client-side certificate. The certificate will be presented to any server in the transaction that requests it. For more information about adding a client certificate, see Adding a Client Certificate to HTTP Server Test Settings.

Allow unsafe legacy renegotiation

Allows TLS renegotiation with older servers that do not support the secure renegotiation extension (RFC 5746). This setting applies to all connections made during the transaction.

Transaction Test HTTP Communication and Performance Settings

Setting
Description

Timeout

Defines the maximum time the browser will wait for each individual page within the transaction to finish loading before failing the step.

Target response time

Sets a performance threshold for the Page Load Time metric for each page view in the transaction. If a page takes longer to load than this value, it will be flagged with a performance warning.

Enable distributed tracing

When enabled, adds an HTTP trace context header to all requests made during the transaction. This allows the entire user journey to be tracked across multiple backend services.

Desired status code

Verifies that the main document for each page loaded during the transaction returns a specific HTTP status code or a code within a range (e.g., 2xx or 3xx).

Verify content

Verifies that the response body for each page loaded during the transaction contains (or does not contain) specific text. This is useful for validating that the correct content was served at each step.

Limit download size

Sets a maximum download size for each object loaded by the browser during the transaction. This helps manage test duration and data consumption.

HTTP version

Selects the preferred HTTP protocol version for all connections made by the browser during the transaction.

  • Prefer HTTP/2: (Default) Uses HTTP/2 if the server supports it, falling back to HTTP/1.1 if not.

  • HTTP/1.1 Only: Forces the test to use only the HTTP/1.1 protocol.

Request method

The HTTP method used for the initial request to the starting URL of the transaction. Subsequent navigations within the script will use the appropriate method (e.g., GET for link clicks, POST for form submissions) as determined by the browser.

Follow redirects

When enabled, the browser will follow all HTTP 3xx redirect responses encountered during the transaction. This is standard browser behavior and is recommended for accurately simulating a user journey.

User agent

Sets the User-Agent string in the HTTP request header for the entire transaction, simulating a specific browser or client.

Override DNS

Maps a specific hostname to a custom IP address for the entire transaction, bypassing public DNS. This is useful for testing pre-production environments.

Custom HTTP headers

Adds custom headers to HTTP requests made during the transaction. Headers can be applied to:

  • Root request: The initial request to the starting URL only.

  • Specific domain: Requests to a specified domain encountered during the script.

  • All domains: All requests made during the test, including those for embedded objects.

Scheme

Selects the HTTP authentication method to be used if a server challenges for credentials at any point during the transaction.

  • Basic: Uses a simple username and password.

  • NTLM: A challenge-response protocol used for integrated authentication in Windows environments.

  • Kerberos: Uses network credentials for single sign-on (SSO) in enterprise environments.

Show HTTP headers in waterfalls

Controls whether the full request and response headers for each object are displayed in the test results' waterfall view.

Transaction Test Transaction Performance and Browser Settings

Setting
Description

Timeout

Defines the maximum time (default 10s) the browser will wait for each individual page within the transaction to finish loading before failing the step.

Target Response Time

Sets a performance threshold (default 6s) for the Page Load Time metric for each page view in the transaction. If a page takes longer to load than this value, it will be flagged with a performance warning.

Chromium Version

Selects the version of the Chromium browser used by the agent for the entire transaction.

  • Default: Uses the standard, stable version of Chromium.

  • Newer when available: Automatically uses the latest available Chromium version, which may include new features but could affect performance consistency.

> Note: The current default Chromium version is 132.

Screenshot

Controls when screenshots are captured during the transaction. This can be set to capture on page load, only when an error occurs, or after every scripted step to provide a visual record of the user journey.

Preferred Language

Sets the Accept-Language header and browser locale for the entire transaction. Some websites use this to serve localized content. Default is English (US).

Microphone and Camera

Controls whether the browser grants or denies permission for web pages to access the system's microphone and camera during the transaction.

Geolocation

Controls whether the browser grants or denies permission for web pages to access the Geolocation API during the transaction.

Page Loading Strategy

Determines when the browser considers each page navigation within the script complete.

  • Normal: (Default) Waits for the full page load, including all sub-resources like images and scripts.

  • Eager: Waits only for the initial HTML document to be downloaded and parsed (DOMContentLoaded event).

  • None: Returns immediately after the initial HTML is received.

Device Emulation

Simulates the viewport of different device types (Desktop, Laptop, Phone, Tablet) for the entire duration of the transaction.

HTTP Headers in Waterfall

Controls whether the full request and response headers for each object are displayed in the waterfall view for all page loads within the transaction.

Exclude Domains / Object URLs

Prevents the browser from loading objects from specified domains or URLs throughout the entire transaction. Use this to isolate the performance of your own application by excluding third-party scripts, ads, or trackers.

Transaction Test Additional Settings

Setting
Description

Description

An optional, user-defined description for the test. Use this field to add context, change history, or other notes for fellow users.

Alert suppression window

Temporarily disables all alerts for this test for a defined period. Use this feature for planned maintenance windows to prevent false-positive alerts.

FTP Server Test

FTP server tests are designed to monitor the availability and performance of FTP, FTPS, or SFTP servers by measuring file transfer operations (e.g., uploads, downloads, directory listings). These tests collect metrics such as availability, response time, throughput, and error details to provide insights into the health and efficiency of file transfer services. To learn more about FTP, see File Transfer Protocol.

Use Cases for FTP Server Tests

  • Monitoring FTP Server availability and accessibility to ensure FTP, FTPS, or SFTP servers are consistently available for users or automated systems to access files

  • Assessing file transfer performance to measure the speed and efficiency of file uploads, downloads, or directory listings to ensure optimal user experience

  • Troubleshooting file transfer issues to diagnose why file transfers fail or perform poorly for users or applications

  • Validating secure file transfer protocols (FTPS/SFTP) to ensure they are properly configured and perform reliably

FTP Server Test Metrics

FTP server tests collect metrics that capture the performance and success of file transfer operations, covering the entire request lifecycle from DNS resolution to data transfer completion.

  • Availability (%): Percentage of successful FTP, FTPS, or SFTP operations (e.g., file upload, download, directory listing), defined as receiving a 2xx FTP reply code.

  • Response Time (ms): Total time from initiating the FTP request to receiving the first byte of the response (time-to-first-byte), encompassing DNS resolution, TCP connection (or SSH for SFTP), protocol negotiation (e.g., SSL for FTPS), and waiting for the server’s initial response.

  • Throughput (MB/s): The data transfer rate, measured in megabytes per second, calculated as the Wire Size (bytes transferred) divided by the Transfer Time (time from first to last byte of the file transfer). It reflects the efficiency of file transfer.

  • Connect Time (ms): Time to establish a TCP connection to the FTP server (or SSH for SFTP).

  • DNS Time (ms): Time to resolve the FTP server’s domain name to an IP address via DNS lookup.

  • Negotiation Time (ms): Time to complete protocol-specific handshakes after the TCP connection, including SSL/TLS negotiation for FTPS, SSH authentication for SFTP, or FTP authentication (e.g., username/password verification).

  • Wait Time (ms): Time from issuing the FTP command (e.g., RETR for download, LIST for directory listing) to receiving the first byte of the server’s response, reflecting server processing time.

  • Transfer Time (ms): Time to transfer the entire file or data (from first to last byte), also known as Receive Time, for operations like uploads, downloads, or directory listings.

  • Wire Size (bytes): The total size of the data transferred over the network during the FTP operation, including file content and protocol overhead, measured in bytes.

  • Error Details: Specific errors encountered during the FTP operation, such as FTP reply codes (e.g., 550 File Unavailable, 530 Login Incorrect), connection timeouts, or protocol errors (e.g., SSL handshake failure for FTPS).

FTP Server Test Views

  • Timeline (FTP Server Layer)

  • Map

  • Table

The FTP server test below monitors speedtest.tele2.net:21.

Other Included Tests

  • Agent-to-server test

  • BGP test

Manually Configuring FTP Tests

FTP Server Basic Settings

  • URL: Specify

    • Protocol (FTP, SFTP or FTPS)

    • Domain name and port number of the server, separated by a colon. If the port number is omitted, the defaults are:

      • FTP: 21

      • FTPS: 990

      • SFTP: 22

    • Path to the file ("Download" and "Upload" Request Types) or directory on the server ("List" Request Type). Depending on the protocol, you will need either an absolute path (starting point is the root directory, "/") or a relative path (starting point is relative to the user's home directory or other directory per the server configuration). FTP and FTPS use relative paths. SFTP uses an absolute path or a relative path.

  • Username/Password: Enter the username and password for the FTP account. The username and password are both required. To perform anonymous FTP, enter “anonymous” as the username and your email as the password.

  • Request Type: Select “Download” to retrieve a file from the FTP server. Select “Upload” to send a file to the FTP server. Select “List” to retrieve a listing of the files in the directory specified by your URL setting. Downloads and uploads use "Image" (binary) transfer; listings use "ASCII" transfer.

    Note: The Upload setting will use a random sequence of bytes as the contents of the file upload. The remote filename will be taken from the URL field. It is not possible to specify the file contents, but the size of the file can be specified by the Upload File Size selector. The maximum recommended file size is 2,147,483 Kb.

  • Limit Download Size/Upload File Size: The number of kilobytes (kB) at which to stop the transfer. Useful for transfers of large files, particularly with slow transfer rates which could result in reaching the test’s Timeout setting prior to completion.

    NOTE: Do not use the Limit Download Size or Upload File Size settings in combination with the Desired Reply Code setting.

  • Verify Content: (List Request Type only) Check the Enable box and enter a regular expression in the field below to verify that a filename or other string(s) is present in your directory listing.

FTP Server Test Advanced Settings

  • Request Mode: Select “Passive” or “Active” mode FTP. The request mode governs the whether the client or server initiates the data channel’s TCP connection. Passive mode is the more common mode, and is the mode used by web browsers when retrieving files via FTP. Active mode requires an inbound TCP connection to port 20 on the Agent performing the test. If your Agent is an Enterprise Agent, then ensure that the firewall or packet filter rules allow this connection if you have selected Active FTP request mode.

  • Desired Reply Code: Enter the reply code that will represent successful test completion. An FTP command can generate multiple reply codes; the Desired Reply Code setting checks the last reply code in the response. For a list of FTP reply codes, consult RFC 959.

    NOTE: Do not use the Desired Reply Code setting in combination with the Limit Download Size or Upload File Size settings.

Manually Configuring Web Layer Tests

Web Layer Tests Basic Configuration

  • Test type: HTTP server, Page Load, or Transaction

  • Test Name: This optional parameter gives the test a label. Where no label is provided, the value in the URL field will be used as the test name, along with a protocol ("http://" by default) prepended.

  • URL: A URL, domain name or IP address, including TCP port. If a domain name or IP address is used (i.e. protocol specification is not provided) then "http://" is assumed.

  • Interval: How frequently this test will be run.

  • Agents: This drop-down lists the ThousandEyes Cloud Agents and (optionally) Enterprise Agents that are available to your account. Select one or more agents to assign them to this test.

  • Alerts: When the Enable box is checked, the alert rules selected in drop-down list will be active for the test. You can select alert rules with the drop-down list, and create, modify and delete alert rules with the Edit Alert Rules link.

  • Transaction Script: Transaction tests execute custom Selenium WebDriver-based scripts written in JavaScript language to simulate user interaction with web page elements. Pictured below are several buttons used to insert regularly used code into transaction tests.

    Each is detailed below, ordered from left to right:

    • Sleep Adds a sleep function set to wait 5 seconds.

    • Marker Adds a marker function to track script progress. Note that this can be changed from markers.set to markers.start and makers.stop to track a particular section.

    • Screenshot Captures a screenshot.

    • Credential Opens credential management options.

Web Layer Tests Advanced Settings

  • Advanced Settings: Provides configuration of an associated Network test for the target server(s), per the Network Test Advanced Settings tab, and provides the following settings for either the selected test type or an associated HTTP Server view, as indicated below:

    • HTTP Server Timing

      • Timeout: Seconds until the test type terminates due to an unresponsive target server. For HTTP server test, the default timeout is 5 seconds. The maximum timeout value is 60 seconds.

      • Target Time for View: Sets the color legend on the global map, and the corresponding font colors for the Agent results table. For example, Response Time for an HTTP server test sets the range of the legend from 0 seconds (green end) to 2x the Target Time for View (red end). Colors for results up to .5x the Target Time for View will be green; between .5x and 1x will be yellow.

    • Page Load Timing/Transaction Timing

      • Timeout: Seconds until the test type terminates due to inability to load the page in a page load test or to complete the script in a transaction test within the timeout time. Defaults and maximum values vary by type of Web test:

        • For page load tests, the default timeout is 10 seconds. The maximum timeout value is either 0.25 * interval (in seconds) or 60 seconds, whichever is lower.

        • For transaction tests, the default timeout is 30 seconds. The maximum timeout value is either 0.5 * interval (in seconds) or 180 seconds, whichever is lower.

      • Note that the HTTP server timeout cannot exceed the page load timeout. For example, if the test interval for the page load test is set to 2 minutes and the rule is to limit the HTTP server timeout to 0.25 * the interval, the HTTP server timeout will be 30 seconds. Since the maximum timeout for this particular page load test is 30 seconds, the HTTP timeout is set to a maximum of 29 seconds in this case.

      • Target Time for View: Sets the color legend on the global map, and the corresponding font colors for the Agent results table. For example, Response Time for a page load test sets the range of the legend from 0 seconds (green end) to 2x the Target Time for View (red end). Colors for results up to .5x the Target Time for View will be green; between .5x and 1x will be yellow.

    • Proxy Settings

      • Direct: Do not use proxy.

      • Enterprise Agent's proxy configuration: Use the agent's proxy configuration.

      • Specific proxy configuration: Choose from one of the in-app proxy configurations to use.

    • HTTP Authentication

      • Username: The username for the account being accessed by the HTTP request(s).

      • Password: The password for the account being accessed by the HTTP request(s).

      • Scheme: The following are available

        1. HTTP Basic Authentication

        2. NTLMv2 (a.k.a. Windows Integrated) Authentication. NTLMv2 authentication is supported for HTTP server tests only.

        3. Kerberos: Selecting the Kerberos button from the Advanced Settings tab > HTTP Authentication options will have the test use the Kerberos configuration on each agent. The agents selected in the test will also need to be setup for Kerberos authentication in the Network & App Synthetics > Agent Settings > Enterprise Agents > Kerberos Settings subtab. See Kerberos Settings for more information.

        4. OAuth (HTTP server only), two Initial Authentication Schemes supported with OAuth as under:

          1. Basic Authentication

          2. NTLM

    • HTTP Request

      • HTTP Version: Select the HTTP version for requests:

        • Prefer HTTP/2: Attempt HTTP/2 and fallback to HTTP/1.1 if HTTP/2 is not available.

        • HTTP/1.1 Only: Send request(s) using HTTP/1.1 only, no attempt is made to utilize HTTP/2.

      • Window Size (page load and transaction tests only): Select size and orientation (phone or tablet) from the various Desktop, Phone and Tablet options available, or configure a custom size. Defaults to Desktop Small (1024x768).

      • Request Method: (HTTP server only) Select the HTTP request method--either GET or POST. If POST is selected, you may specify data in the POST Body field. The default is GET.

      • SSL Version: Select the version of the SSL/TLS protocol to offer in the SSL Client Hello. This will set the maximum version of SSL/TLS that the connection can use, but a lower version may be negotiated by the server. The options are the following:

        • SSLv3: Use SSL version 3.0. No lower version can be negotiated.

        • TLSv1.0: The Agent will start the TLS negotiation at version 1.0.

        • TLSv1.1: The Agent will start the TLS negotiation at version 1.1.

        • TLSv1.2: The Agent will start the TLS negotiation at version 1.2.

        • Auto: The Agent will start the TLS negotiation at the highest version of TLS supported by its operating system. Currently the highest version is TLS 1.2 Contact [email protected] if you require confirmation of the current version.

      • Verify SSL certificate: (HTTP server only) By default, certificate-related errors will result in a test error. Uncheck this box to ignore certificate errors during SSL/TLS negotiation.

      • Agent ID Strategy: (page load and transaction only) HTTP requests originating from a transaction or page load test must be identifiable as being a ThousandEyes Agent request. The default identification strategy is to include a custom header (X-ThousandEyes-Agent: yes) on each request. However, in certain situations, the inclusion of this this header can cause a CORS policy violation for some cross-origin requests. To circumvent this issue, HTTP requests can alternatively be made identifiable by instead extending the User Agent request header with the (ThousandEyes Agent) identifier string. Selecting the Extend User Agent Header option will automatically include this identifier string and it will be appended into User Agent text input. If the (ThousandEyes Agent) identifier string is removed from the User Agent text input while the Extend User Agent Header option is selected, the test configuration will not be valid and cannot be saved.

      • Custom Headers: Enter one or more HTTP header strings in the form <stringname>: <value>. Note the whitespace between the literal colon character and the placeholder <value>. The custom header(s) will be transmitted with the target page request (page load test) or each page request (transaction test) but not for objects within a page. When adding multiple headers, delineate between individual headers using a line break.

      • Override DNS: (HTTP server only) Instead of using standard DNS resolution, allows you to specify the IP address to which the target's domain name will resolve. Note that the specified IP address is not that of a DNS server, but the IP address that will be used as the target for the test. This setting is useful for targeting a specific server within a cluster, or when testing HTTPS URLs that require a Server Name Indication (SNI) in the TLS negotiation that is different from the domain name-to-IP address mapping required to access the URL.

      • Client Certificate: (HTTP server only) Configure a client-side certificate, which will be sent in the SSL handshake to the web server to authenticate the client. Check the Enable box, then copy your client certificate (both the private key and the public certificate) in PEM format and paste into the Client Certificate field.

        If your certificate is in PKCS#12 format (.pfx file extension), you may use the openssl utility to create a PEM version. For example, the openssl command for a client certificate mycert.pfx with a password would be:

        openssl pkcs12 -in mycert.pfx -out clientcert.pem -nodes -passin pass:<password>

        Then edit the output file clientcert.pem using a text editor to remove any text before, after, or in between the certificate and private key. The file should look like the following:

        -----BEGIN RSA PRIVATE KEY-----
        MIIEpQIBAAKCAQEAtjjpbonL7xK2AiVPo7/n0uQiwjk3hN0B3bAR0wVPt6UYLc2h
        L+T5UOOU5xlNu1ydz2iyxbcV8sn6rtT4NGyRgeh91A+GvCRzR2GMH5vocNMNSuYh
        <lines omitted for brevity>
        Nx6ZWZekTlYrelnIM6FsUVUplwlYxU9UqBWeYcLx6BkrKKzoohFSTstI4PhuzE4P
        lSD/opYrkwCYiNmNX4Z8SU136fbz43FhFUNzmEePNEVLJ2mF0f2Y+ek=
        -----END RSA PRIVATE KEY-----
        -----BEGIN CERTIFICATE-----
        MIIEGzCCAwOgAwIBAgIJAOUXm6K8B9tnMA0GCSqGSIb3DQEBCwUAMIGjMQswCQYD
        VQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5j
        <lines omitted for brevity>
        T4QRFKjtQiTzkGl4NT+wiLi+JLS3sQVpsmfqJ5cBLf91GOpFWQs65Kc7JdUfezs=
        -----END CERTIFICATE-----

        NOTE: The private key must be placed first, then the certificate.

      • Unsafe Legacy Renegotiation: (HTTP server only) Allows TLS renegotiation with servers that do not support Secure Renegotiation described in RFC 5746. This option is enabled by default for all tests with HTTP options, but can be disabled by unchecking the box.

    • HTTP Headers

      • Show HTTP headers in waterfalls: (page load and transaction) Make available HTTP request and response header information for each object in the waterfall displays.

    • HTTP Response

      • Desired Status Code: (HTTP server and page load) Sets the HTTP status code returned by the server that is defined as a successful test (i.e. no errors will be displayed in the test table results, no response code-based alerts generated, etc...). By default, either a 200-level or 300-level status code is considered a successful return code. Uncheck the box and enter a response code in the field below to use a different response code.

      • Verify Content: (HTTP server only) Search the HTTP response headers and body (similarly to a curl -i command) for text matching a given POSIX regular expression. Headers and body are searched separately. If no match occurs, the test shows an error condition. Note: the HTTP server test does not execute any JavaScript code, therefore the content generated by JavaScript cannot be verified by this feature. JavaScript-generated content can be matched using a transaction test.

      • Limit Download Size: (HTTP server only) Load only the first number of kiloBytes (kB) specified in the field below the Enable box. The result is not guaranteed to be exactly the number specified, but can be slightly more--but always within a few percent, or less as the size of the download is increased. Note that this function does not use an HTTP Range header, so the HTTP response code should not be affected (i.e. success is a 200 OK response, not a 206 Partial Content response).

Web Layer Test Outputs

  • HTTP server tests provide a world map containing availability, and on location-by-location basis, the response code served by the target web page, and number of redirects from URL requested until the final page was served.

  • Page load tests provide all the content from an HTTP server test, along with a page load table, showing the breakdown of the data received by domain and provider, as well as a waterfall chart, which shows the load time, source and provider for each component of the page. The page load test also provides access to DOM load and page load times, which provide elapsed times from the request start.

  • Transaction tests provide page load detail for each page visited in a transaction, timing information for custom defined markers, screenshots (if configured) as well as overall transaction time and completion percentage, on an agent-by-agent basis.

  • FTP server tests provide availability, response time and throughput metrics, as well as FTP reply codes for an FTP session.

Last updated