Requirements for private Synthetic locations

Calculated as 5000 monitor executions (maximum for a single environment) run once every minute (maximum frequency).

These are HTTP monitors on private locations with any of: pre- or post-execution scripts, OAuth2 authorization, Kerberos authentication.

For NAM monitors using ICMP request type, capacity is related to number of ICMP echo requests (packets) that are being sent during monitors execution. As this number of packets-to-be-sent may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.

For NAM monitors using TCP and DNS request types, capacity is related to the number of network connections (requests) that are being sent during monitors execution. As this number of requests may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.

During load tests that helped to establish capacity limits, NAM ICMP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Monitors were using default settings (including default timeouts settings and single packet per-request) and were scheduled every 1 minute. There were multiple target hosts used during tests; all of them were responding properly with average RTT around 200ms.

During load tests that helped to establish capacity limits, NAM TCP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Monitors were using default settings (including default timeouts settings) and were scheduled every 1 minute. There were multiple target hosts and ports used during tests; all of them were responding properly with average TCP connection time around 200ms.

During load tests that helped to establish capacity limits, NAM DNS monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Please note that DNS server used during resolution should be able to handle incoming requests and may not consider the incoming traffic as a subject to throttling or rejection (for example, due to detection as bot-originated). Monitors were using default settings (including default timeouts settings and UDP as a transport) and were scheduled every 1 minute. There were multiple resolution targets used during tests; all of them were resolved properly with average DNS resolution time around 10ms. Publicly available DNS servers were used: Google (8.8.8.8 and 8.8.4.4) and Cloudflare (1.1.1.1 and 1.1.1.2)

Calculated as 5000 monitor executions (maximum for a single environment) run once every minute (maximum frequency).

These are HTTP monitors on private locations with any of: pre- or post-execution scripts, OAuth2 authorization, Kerberos authentication.

For NAM monitors using ICMP request type, capacity is related to number of ICMP echo requests (packets) that are being sent during monitors execution. As this number of packets-to-be-sent may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.

For NAM monitors using TCP and DNS request types, capacity is related to the number of network connections (requests) that are being sent during monitors execution. As this number of requests may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.

During load tests that helped to establish capacity limits, NAM ICMP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Monitors were using default settings (including default timeouts settings and single packet per-request) and were scheduled every 1 minute. There were multiple target hosts used during tests; all of them were responding properly with average RTT around 200ms.

During load tests that helped to establish capacity limits, NAM TCP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Monitors were using default settings (including default timeouts settings) and were scheduled every 1 minute. There were multiple target hosts and ports used during tests; all of them were responding properly with average TCP connection time around 200ms.

During load tests that helped to establish capacity limits, NAM DNS monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Please note that DNS server used during resolution should be able to handle incoming requests and may not consider the incoming traffic as a subject to throttling or rejection (for example, due to detection as bot-originated). Monitors were using default settings (including default timeouts settings and UDP as a transport) and were scheduled every 1 minute. There were multiple resolution targets used during tests; all of them were resolved properly with average DNS resolution time around 10ms. Publicly available DNS servers were used: Google (8.8.8.8 and 8.8.4.4) and Cloudflare (1.1.1.1 and 1.1.1.2)

Calculated as 5000 monitor executions (maximum for a single environment) run once every minute (maximum frequency).

These are HTTP monitors on private locations with any of: pre- or post-execution scripts, OAuth2 authorization, Kerberos authentication.

For NAM monitors using ICMP request type, capacity is related to number of ICMP echo requests (packets) that are being sent during monitors execution. As this number of packets-to-be-sent may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.

For NAM monitors using TCP and DNS request types, capacity is related to the number of network connections (requests) that are being sent during monitors execution. As this number of requests may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.

During load tests that helped to establish capacity limits, NAM ICMP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Monitors were using default settings (including default timeouts settings and single packet per-request) and were scheduled every 1 minute. There were multiple target hosts used during tests; all of them were responding properly with average RTT around 200ms.

During load tests that helped to establish capacity limits, NAM TCP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Monitors were using default settings (including default timeouts settings) and were scheduled every 1 minute. There were multiple target hosts and ports used during tests; all of them were responding properly with average TCP connection time around 200ms.

During load tests that helped to establish capacity limits, NAM DNS monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Please note that DNS server used during resolution should be able to handle incoming requests and may not consider the incoming traffic as a subject to throttling or rejection (for example, due to detection as bot-originated). Monitors were using default settings (including default timeouts settings and UDP as a transport) and were scheduled every 1 minute. There were multiple resolution targets used during tests; all of them were resolved properly with average DNS resolution time around 10ms. Publicly available DNS servers were used: Google (8.8.8.8 and 8.8.4.4) and Cloudflare (1.1.1.1 and 1.1.1.2)

Calculated as 5000 monitor executions (maximum for a single environment) run once every minute (maximum frequency).

These are HTTP monitors on private locations with any of: pre- or post-execution scripts, OAuth2 authorization, Kerberos authentication.

For NAM monitors using ICMP request type, capacity is related to number of ICMP echo requests (packets) that are being sent during monitors execution. As this number of packets-to-be-sent may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.

For NAM monitors using TCP and DNS request types, capacity is related to the number of network connections (requests) that are being sent during monitors execution. As this number of requests may significantly vary among defined monitors, using the number of monitor executions as a capacity limit would be inaccurate.

During load tests that helped to establish capacity limits, NAM ICMP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Monitors were using default settings (including default timeouts settings and single packet per-request) and were scheduled every 1 minute. There were multiple target hosts used during tests; all of them were responding properly with average RTT around 200ms.

During load tests that helped to establish capacity limits, NAM TCP monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Monitors were using default settings (including default timeouts settings) and were scheduled every 1 minute. There were multiple target hosts and ports used during tests; all of them were responding properly with average TCP connection time around 200ms.

During load tests that helped to establish capacity limits, NAM DNS monitors were exclusively scheduled on location; monitors had the following characteristic. Actual capacity may be different for other environments (for example, those where monitored targets respond slower or are failing to provide a response within timeout limit or other type of monitors are executed at the same time). Please note that DNS server used during resolution should be able to handle incoming requests and may not consider the incoming traffic as a subject to throttling or rejection (for example, due to detection as bot-originated). Monitors were using default settings (including default timeouts settings and UDP as a transport) and were scheduled every 1 minute. There were multiple resolution targets used during tests; all of them were resolved properly with average DNS resolution time around 10ms. Publicly available DNS servers were used: Google (8.8.8.8 and 8.8.4.4) and Cloudflare (1.1.1.1 and 1.1.1.2)