HTTP Server Tests
HTTP Server tests measure the availability and performance of any web service, whether it's on the public internet or an internal network monitored by Enterprise Agents. Each test measures key metrics like availability, response time, and throughput by simulating the steps a client takes to access a web page.
When a test runs, it executes a series of phases and pinpoints failures at the exact step where they occur:
DNS: Resolves the URL's domain to an IP address.
Connect: Performs a TCP three-way handshake with the server.
SSL (Optional): Completes the TLS/SSL negotiation for HTTPS connections.
Send: Sends the configured HTTP request to the server.
Receive: Waits for and receives the server's HTTP response.
HTTP Validation: Validates the HTTP response status code.
Content Verification (Optional): Verifies the response body against a specified text or regular expression.
To provide a complete picture for troubleshooting, HTTP Server test results are automatically correlated with underlying Network and BGP layer data. The test also supports advanced configurations, including custom headers, various authentication schemes, and specific SSL/TLS settings.
HTTP Server tests are part of the ThousandEyes Web Layer monitoring suite. To learn more, see Web Layer Tests.
Use Cases for HTTP Server Tests
HTTP Server tests can be used to monitor any HTTP-based service. Here are some common scenarios where they provide critical visibility:
Monitor Core Website Availability and Performance
Continuously verify that your websites and web applications are online and responsive for your users.
Problem: You need to know immediately if your website is down or performing poorly.
Solution: Schedule HTTP Server tests to run at frequent intervals from global locations. Track key performance indicators (KPIs) like availability and response time to ensure you meet Service Level Agreements (SLAs) and provide a positive user experience. Configure alerts to be notified instantly of outages or performance degradations.
Verify Multi-Cloud and Data Center Performance
For applications hosted across multiple data centers or cloud regions, ensure each instance is healthy and serving users correctly.
Problem: Your application is globally distributed, and you need to validate that traffic is being routed to the optimal location, such as the closest or best-performing data center.
Solution: Run tests from various agent locations to simulate a global user base. This allows you to verify that your load balancing (GSLB, Anycast) is working as intended and helps you identify and troubleshoot region-specific performance issues.
Validate CDN Performance and Content Delivery
Ensure your Content Delivery Network (CDN) is accelerating content delivery and improving user experience as expected.
Problem: You need to confirm that your CDN is serving content from the correct edge locations and that caching is effective.
Solution: Deploy tests from global locations to measure latency improvements. By inspecting HTTP response headers, you can confirm caching behavior, such as cache hits vs. misses, and verify that users are being directed to the nearest CDN edge node, ensuring optimal performance.
Monitor API Endpoints and Critical Services
Ensure the availability and responsiveness of business-critical APIs and microservices that power your applications.
Problem: A backend API failure can break your application, even if the main website is online. You need to monitor these critical dependencies.
Solution: Configure tests to target specific API endpoints. Use features like POST requests, custom headers for authentication tokens, and content verification to validate not just that the API is reachable, but that it returns the correct data payload, ensuring end-to-end service health.
HTTP Server Metrics
HTTP Server Tests collect metrics that capture the entire lifecycle of an HTTP/HTTPS request, from DNS resolution to receiving the server’s response. The metrics are:
Availability (%): Percentage of successful HTTP requests, typically defined as requests returning a 2xx or 3xx status code.
Response Time (ms): Total time to complete the HTTP request, encompassing DNS resolution, TCP connection, SSL handshake (if HTTPS), sending the request, waiting for the server’s response, and receiving the response.
Throughput (MB/s): The data transfer rate, measured in megabytes per second, calculated as the Wire Size (bytes transferred) divided by the Receive Time (time from first byte to last byte of the response payload). It reflects the efficiency of data delivery from the server.
Redirect Time (ms): The time spent processing HTTP redirects (e.g., 301, 302 status codes), from receiving a redirect response to initiating the request to the new URL, including any additional DNS resolution, connection, or SSL handshake for the redirected endpoint.
Connect Time (ms): Time to establish a TCP connection to the server.
DNS Time (ms): Time to resolve the target domain’s DNS record.
SSL Time (ms): Time to complete the SSL/TLS handshake (only for HTTPS endpoints).
Wait Time (ms): Time waiting for the server to begin responding (e.g., time to first byte, reflecting server processing).
Receive Time (ms): Time to receive the full response from the server.
Wire Size (bytes): The total size of the HTTP response data transferred over the network, including headers and body, measured in bytes.
Response Code: The HTTP status code returned by the server (e.g., 200 OK, 404 Not Found, 500 Internal Server Error), indicating the outcome of the HTTP request.
Error Details: Specific errors encountered, such as HTTP status codes (e.g., 404 Not Found, 500 Internal Server Error), DNS failures, or timeouts.
Error Types for HTTP Server Tests
DNS
Failure to resolve a domain name to one or more IP addresses using DNS
Connect
Failure to complete a TCP 3-way handshake (SYN, SYN-ACK, ACK)
SSL (if test target using SSL/TLS)
Failure to complete SSL/TLS negotiation
Send
Failure to complete sending of an HTTP GET or POST request
Receive
Failure to receive a valid and complete HTTP response
HTTP
Receiving an HTTP response code that is not (default) 2XX or 3XX, or not the desired HTTP status code of the response as configured in Advanced Settings of the test
Content (optional)
Failure to match returned content to an expression in the Verify Content field
HTTP Server Test Views
HTTP Server Tests provide the the following views:
Timeline (HTTP Server Layer-- focuses on application-layer metrics such as Availability, Response Time, DNS Time, etc.)
Map
Table
HTTP Server tests provide a world map that visualizes availability from each agent's location. On a per-location basis, the view also shows the final HTTP response code and the total number of redirects required to reach the target page. The HTTP server test below measures the availability of the https://thousandeyes.okta.com/ service:
Other Included Tests
Agent-to-server test
BGP routing test
Manually Configuring HTTP Server Tests
To configure an HTTP Server test:
In the ThousandEyes platform, navigate to Network & Synthetics > Test Settings.
Click the + button in the upper right corner of the screen.
Under the Web & API Tests section, select the card titled HTTP Server Performance.
The configuration page is divided into three sections: Basic Settings, Network and Security Settings, HTTP Communication and Performance, and Additional Settings.
HTTP Server Test Basic Settings
URL
The full URL of the web server to test. The URL must include the protocol (http or https) and domain name, and can optionally include a port number and path.
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 and Enterprise Agents 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.
HTTP Server Test Network and Security Settings
Test execution schedule
Determines the timing of test rounds for all assigned agents.
Default: All agents start the test simultaneously at each interval. Use for synchronized data collection and baseline comparisons.
Randomized: Staggers agent start times randomly within the test interval. Use to prevent traffic bursts and simulate more realistic user behavior.
Define which data to collect
Select the types of network data to collect during the test.
Perform network measurements: Enables the collection of core network metrics like loss, latency, and jitter.
Perform bandwidth measurements: 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.
Perform MTU measurements: 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.
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.
Adding a Client Certificate to HTTP Server Test Settings
To configure a client-side certificate, which will be sent in the SSL handshake to the web server to authenticate the client, click the Add client certificate toggle. Copy your client certificate (both the private key and the public certificate) in PEM format and paste into the text field below the toggle.
If your certificate is in PKCS#12 format (.pfx file extension), you can 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:
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:
NOTE: The private key must be placed first, then the certificate.
HTTP Server Test HTTP Communication and Performance Settings
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.
Kerberos: Uses network credentials for single sign-on (SSO) in enterprise environments.
OAuth: Uses a bearer token for modern API authentication.
HTTP Server Test Additional Settings
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.
Last updated