Test parameters
Each test has different parameters that define how the test measures and behaves. Which parameters you can configure and what values are meaningful is mainly determined by the test method.
Test method
The test method mainly determines how a test measures the performance or availability of a target. Below are short summaries and links to detailed method descriptions provided.
ICMP (ping)
The ICMP method relates to the ICMP protocol which is usually the standard protocol for a simple ping request. A single measurement sends a ICMP packet to the specified IP address or hostname and measures the round-trip-time.
DNS resolution
The DNS resolution does a DNS lookup (like nslookup using cmd).
A single measurement tries to resolve the target hostname using the standard DNS server. The response time of the DNS server is measured.
HTTP(S)
The HTTP(s) method relates to the HTTP(s) protocol. A single measurement sends an HTTP request to the specified URL using either HEAD or GET as request method and measures the round-trip-time. In addition the status code of the response validated. Either only success codes (2xx) are accepted or a custom status code (ranges) can be specified.
TCP
The TCP method relates to the TCP protocol. A single measurement sends a TCP request to the specified target hostname and measures the round-trip-time. By default port 443 is used. The general validity of the returned TLS certificate (e.g. that it is trusted or not expired) can optionally be checked.
MS-TURN (udp)
The MS-TURN method uses the UDP protocol to send packets to the Microsoft Teams TURN server via port 3478. The round-trip-time of a single UDP packet is measured.
Execution schedule
Each test is executed every minute. During each test run one or multiple measurements are executed. The number of measurements per minute can lie between 0 and 58 for the ICMP (ping), TCP and HTTP(S) methods.
A test using the DNS resolution method only measures once per minute.
A test using the MS-TURN method measures either once or 50 times per second.
Test events
For each test run an overall status is calculated which can be success, warning, critical or error. This overall test run status is generally based on the status of the single measurements of a test run and the status percentage. For HTTP and the TCP methods there are also other factors that influence the test run status.
Status treshholds
The status thresholds determine the status of a single measurement. Therefore, the thresholds mainly control the health of your tests. There are two status treshholds: A warning threshold and a critical threshold. The status is then determined as follows:
| Status | Calculation |
|---|---|
| Success | The latency is below the warning threshold (and critical limit) |
| Warning | The latency is above the warning threshold but below the critical threshold |
| Critical | The latency is above the critical threshold (and warning threshold) and below the timeout |
| Error | The measurement didn't return a latency value because the test didn't execute successfully. |
Appropriate warning/critical threholds depend on many factors like the target, method, environment and test scenario. Base thresholds are provided as guideline on the details pages of each test method. However, threshold should be adapted over time by observing the test results.
Status percentage
The status percentage is used to determine, based on the status of all measurements of that run, the test run status.
It defines how much percent of the measurements need to be at least of one status so that this status becomes the overall test run status. The percentage takes the most severe status fullfilling the requirement: success < warning < critical < error.
For example: If the stautus percentage is 20% then at least 20% of the measurements have to have the status critical (or higher) so that the overall test run status is set to critical.
Note
The number of measurements counted for each overall status is always the number of measurements with that status or higher. E.g. for the status critical all measurmenets with status critical and error are counted.
Other influencing factors
Some methods do not only calculate the test run status using the measured latency.
For HTTP(S) methods the returned status code must match for each measurement. Otherwise the measurement status is error, disregarding the latency measured.
For the TCP method a TLS check can be activated optionally. If that TLS check fails at the begin of the test run, this test run also generates an error.