Non-scripted monitor errors

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.

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 where the synthetic's check was performed.

Problem

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

Solution

Add our synthetic monitoring IP addresses to your allow list, to ensure traffic from our synthetic monitors can reach the target server.

Cause

The target server is likely blocking or rate-limiting synthetic's traffic.

Problem

The synthetic monitor encountered an unsuccessful status code, usually a response code that is not in the 2XX/3XX range.

Solution

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

Cause

The cause depends on the response code sent.

Problem

Your monitor returns an SSLVerificationError.

Solution

Go to one.newrelic.com > Synthetics > (select a monitor) > Settings > General > Advanced options, then disable the Verify SSL check.

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.

Problem

The string value included in the synthetic 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 (10^6 bytes) of the response body.

• Simple browsers: The string must be visible on the page when the page’s load event is fired.

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 synthetic monitor HTTP client, or network latency between your server and ours.

Problem

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

Solution

Add our synthetic monitoring IP addresses to your allow list, to ensure traffic from our synthetic 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.

Problem

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

Solution

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

If the failure is occurring on a synthetic monitoring's 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.

Problem

The synthetic 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 New Relic, recreate the issue outside New Relic to troubleshoot the root cause. Use a similar client to perform requests against the target endpoint:

• Ping monitors: HTTP client similar to curl.

• Simple browser and scripted browser monitors: Chrome 60 instance in an Ubuntu 14.04.5 VM.

• Scripted API monitors: Use the request HTTP client for Node.js.

  Cause

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

Problem

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

Solution

Private synthetic monitoring's 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.

Docker: 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 points to the loopback interface such as 127.0.0.1, define a DNS config at the Docker daemon level, or use a tool like dnsmasq to make sure the runner will forward DNS requests on the Docker bridge interface.

Public synthetic monitoring 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 synthetic monitoring locations use Google public DNS and Amazon-provided DNS. If DNS resolution of the target host is failing on our public synthetic monitoring locations, this is likely an issue other users are facing.

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

Problem

The target domain is blocked by synthetic monitoring.

Solution

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

Cause

Synthetic monitoring 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.