Troubleshooting: NimWatch Alerts – Understanding Downtime Errors

This guide will: Help you understand the possible reasons for website downtime errors you receive via NimWatch notification emails. NimWatch is powered by StatusCake, the top-tier uptime monitoring tech.

Downtime error 1: “Domain not found”

Here are the reasons for a “Domain not found” root cause during an uptime test:

• Your domain name can't be resolved using Google and Cloudflare DNS services
• The IP address of your domain might not be directed to the correct record. This can be fixed by modifying the DNS records
• A recent adjustment to DNS records might need some time to propagate across the internet. The adjustment must be fully applied to be recognised during uptime testing testing
• There could be an issue on the part of your domain services provider leading to failures at the DNS stage from one or multiple locations

Downtime error 2: “String match not found/String match found”

Here are the reasons for a "String match not found/String match found" error during an uptime test:

• “String match not found” occurs when the specified string in the test settings is not found in the target URL's page source. The setting on the test defines that we should mark a downtime and send an alert if the specified string is not found on the page
• “String match found” happens when the specified string in the test settings is found in the target URL's page source. The setting on the test defines that we should mark a downtime and send an alert if the specified string is found on the page
• You may see this error due to trying to match a string that is generated past the point of page load by JavaScript or other dynamic scripts. String match can’t check or alert based on this content

Downtime error 3: “Timeout/connection refused”

Here are the reasons for a “Timeout/connection refused” error during an uptime test:

• Connection refusal may result from trying to access a website via unauthorised access, closed ports, or firewall restrictions
• If a site takes too long to load, the system waits a maximum of 75 seconds before marking a timeout. This timing can be lowered by modifying the Crawl Timeout setting on the test
• DNS settings might fluctuate based on the provider, so it's worth checking the status of the DNS provider. Or, if you use any WAF (like Cloudflare), there could be intermittent issues over time, where visitors fail to connect
• When a target server reaches its connection limit – due to regular visitors or connections from bots – the maximum number of connections allowed on the server may have an impact

Downtime error 4: “Unexpected status code”

Here are some possible reasons for an “Unexpected status code” root cause on an uptime test.

When the tested website returns an unusual status code, we return this error type. This could be any common error status code or a custom status code.

Some common status codes that will give an error by default are:

• 400 – The target server refuses to process the request due to a perceived issue with the data being sent
• 403 – Access to the server is forbidden
• 404 – The requested page or file was not found on the server
• 405 – The method is not allowed. For example, you're connecting by POST when the server only accepts GET
• 429 – This is a sign that too many requests have been sent to the target server, and is a common method of rate limiting
• 500 – This indicates an internal server error. The target server doesn’t know how to handle the error
• 503 – The target server is unavailable and unable to handle the request. Common causes include:
  • The server is overloaded
  • The server is down for maintenance