Non-scripted monitor errors

Problem

Your Synthetics ping or simple monitor reported one of the errors below. For scripted monitor errors, see non-ping errors.

Solutions

Below are some of the most common non-scripted monitor error messages.

ERROR: Job timed out after 65 SECONDS

Problem

Your ping timed out after 65 seconds, the non-configurable check duration time limit.

Solution

The 65 second time limit is non-configurable. Pings exceeding 65 seconds may be a result of latency from the target server. Investigate potential issues along the network path between our servers and yours, as this may indicate an issue experienced by real users of your application.

Cause

Ping monitors will first perform a HEAD request. If this request fails for any reason, or reaches the 30 second HTTP connect timeout for ping monitors, then a subsequent GET request is performed. This error happens when both the HEAD and GET request exceed 30 seconds, usually due to server latency.

NetworkError: Connect to <HOST> [<HOST>./<IP ADDRESS>] failed: connect timed out

Problem

HTTP requests during the check exceeded the non-configurable 30 second TCP connection timeout limit.

Solution

The 30 second time limit is non-configurable. Investigate potential issues along the network path between our servers and yours, as this may indicate an issue experienced by real users of your application.

Cause

This failure indicates an issue reaching your site from the location the Synthetics check was performed.

NetworkError: Connect to <HOST> [<HOST>./<IP ADDRESS>] failed: Connection refused (Connection refused)

Problem

The target server refused connection from the Synthetics ping monitor HTTP client.

Solution

Whitelist our Synthetics IP addresses to ensure traffic from our Synthetics monitors can reach the target server.

Cause

The target server is likely blocking or rate-limiting Synthetics traffic.

HTTPError: Server replied with a HTTP XXX response code

Problem

The Synthetics monitor encountered an unsuccessful status code, usually a non-2XX/3XX response code.

Solution

Check your server-side logging to determine why the response code was sent. To assist with identifying Synthetics traffic on your server, all Synthetics monitoring traffic includes an X-Abuse-Info HTTP request header and we provide a list of origin IP addresses for all Synthetics monitoring traffic.

Cause

The cause depends on the response code sent.

SSLVerificationError: <ERROR>

Problem

Your monitor returns an SSLVerificationError.

Solution

Disable the Verify SSL check: Go to synthetics.newrelic.com > (select a monitor) > Settings > Advanced Options .

Cause

SSLVerificationError failures are a result of the optional Verify SSL check failing against the target host.

SSL verification failed during execution for domain <TARGET_URL> failures indicate that the URL provided is not HTTPS or does not redirect to an HTTPS endpoint.

SSLVerificationError: (<ERROR CODE>) <ERROR> errors are retrieved directly from the openssl command and often indicate a legitimate SSL configuration issue on the target site.

ResponseValidationError: Response did not contain the expected string

Problem

The string value included in the Synthetics monitor’s optional Response Validation field was not found in the target server’s response.

Solution

To troubleshoot:

  • Check the failed results timeline to ensure the endpoint where the response validation text is expected, is the last endpoint being requested.
  • Attempt a CURL request against the target endpoint to see if the expected response body is returned.
  • Ensure your endpoint doesn't have policies that will return different content depending on header content or request activity. If so, use a scripted browser to spoof a specific header string.
  • If you’re using a simple browser to monitor a page whose content is loaded via JavaScript after the page’s load event is fired, consider using a scripted browser monitor instead. You can program scripted browsers to wait for specific elements to appear on a page before interacting with them.

Cause

The cause depends on the monitor type:

  • Ping monitors: The string value must be present in the first 1MB of the response body.
  • Simple browsers: The string must be visible on the page when the page’s load event is fired.
NetworkError: Read timed out

Problem

The monitor client was able to establish an HTTP connection to the target site, but then exceeded the 30 second read timeout while waiting for a response.

Solution

To troubleshoot:

  • Investigate the target server's performance during the time period the issue was observed.
  • Investigate potential issues along the network path between our servers and yours, as this may indicate an issue experienced by real users of your application.

Cause

This indicates an issue with the target server responding to the Synthetics monitor HTTP client, or network latency between your server and ours.

NetworkError: Socket is closed

Problem

The Synthetics monitor HTTP client was able to establish a connection to the target server. The target server then closed the connection without a response.

Solution

Whitelist our Synthetics IP addresses to ensure traffic from our Synthetics monitors can reach the target server.

Cause

Edge infrastructure sometimes implements measures such as this for an application endpoint to handle traffic that violates behavior policies like rate limiting.

NetworkError: No route to host (Host unreachable)

Problem

The Synthetics monitor client was able to resolve the target host’s IP address, but was unable to find a route to the target host to establish a connection.

Solution

If the failure is occurring on a public Synthetics location, ensure that the DNS records for this host are resolving to a reachable IP address.

If this is occurring on a Synthetics private location, ensure the private minion’s network configuration is properly configured and that the target hostname is resolvable and reachable via the private minion virtual command line interface.

Cause

This occurs when the target hostname resolves to a non-routable IP address per RFC 1918

HTTPError: Server sent us too many redirects (20)

Problem

The Synthetics monitor client was redirected (observing 301 or 302 response codes) 20 times when performing a request to the target endpoint.

Solution

Ensure that the target endpoint redirects client requests less than 20 times. If this is only occurring within Synthetics, recreate the issue outside Synthetics to troubleshoot the root cause. Use a similar client to perform requests against the target endpoint:

Cause

This occurs when the monitored endpoint effectively serves a redirect loop to the Synthetics monitor: The initial response redirects to another URL which redirects to another URL etc.

NetworkError: DNS resolution failed for host: <HOST>

Problem

The target hostname was not able to be resolved by the Synthetics monitor’s HTTP client.

Solution

  • Private Synthetics locations: Confirm that the network configuration for the minion is correct. If the target hostname is an internal one, ensure that the minion is using your network’s internal DNS service that is able to resolve the host. The containerized private minion and the runner containers it spawns on host (to run non-ping checks) should inherit DNS configuration from the host /etc/resolv.conf.

    Note that network arguments like –dns or -network used in the Docker run command on the containerized private minion will only be used by the minion container, but not the runner containers. If the DNS is pointed to the loopback interface (eg. 127.0.0.1), you will want to define a DNS config at the Docker daemon level and / or use a tool like Dnsmasq to make sure the runner will forward DNS requests on the Docker bridge interface.

  • Public Synthetics locations: Ensure that the target site’s DNS record can be looked up by public DNS services such as Google public DNS and Amazon-provided DNS.

Cause

Our public Synthetics locations use Google public DNS and Amazon-provided DNS. If DNS resolution of the target host is failing on our public Synthetics locations, this is likely an issue other users are facing.

If you are seeing DNS resolution related monitor failures on a Synthetics private Location, this is often caused by the private Minion for that location having an invalid network configuration.

BlockedRequestError: <URL>

Problem

The target domain is blocked by Synthetics monitoring.

Solution

To unblock domains, you must be use a scripted browser monitor and manually make calls in your script.

Cause

Synthetics monitors specifically exclude scripts for popular analytics services such as Google Analytics. This ensures your analytics tools continue to receive accurate data, even with thousands of monitors checking your website each month.

For more help

Recommendations for learning more: