Since its inception StatusCake has never sent a false alert; however there are several reasons in which due to misconfiguration on systems being tested you may get alerted; there are also cases where it may appear to be a false alert but is actually valid. If none of the above applies to you then please get in touch and support will be happy to guide you through a more in depth investigation into any issues you may be encountering.

Checking the Root Downtime Causes

First of all it’s best to check why we marked the site as down, you can do this by going to the test’s details page, and scrolling down to the “Root Downtime Causes” section, here you’ll see a full explanation of why the downtime occurred.

Whitelisting our IPs

The single most common reason for users getting alerts they were not expecting is when they have not whitelisted our IPs on their service. Our system automatically connects to your test with a consistent repeating approach – it’s this style of testing that some firewalls can detect as a form of attack and then block our test agents. If our test agents get blocked then as far as they can tell your site is down.

You can avoid this by whitelisting our IPs in your firewall. How this is done will depend on your system setup and if you’re using Shared Hosting you may need to speak to your host to do this for you. We provide a list of all our IPs in various formats:

https://app.statuscake.com/API/Locations/json
https://app.statuscake.com/API/Locations/xml
https://app.statuscake.com/API/Locations/txt

It’s important to use at least three IP’s per uptime test, this supports the confirmation server mechanic and prevents false results.

Increasing Confirmation Servers

Part of the way that StatusCake avoids sending false alerts is through a range of confirmation servers. These servers allow for your test to be confirmed down on multiple times before sending any alerts. By default we set this to three confirmation servers which we have found is the ideal balance between how long the confirmations take and avoiding any false alerts. Because we want to give our users flexibility we give you the control to reduce this below three – however doing so does lead you more often to receiving alerts that you would not want.

Microdowntime

A lot of the time that a user reports to us false alerts it actually ends up being a very short period of downtime that will be resolved by the time the user checks. Micro Downtime can occur on events such as a server updating or a host rebooting a box.

Content Match Failure

Some users setup content matching on a string on their site which is actually dynamically generated and thus on some pages does not show. This can happen on users who have some form of server caching and then select an HTML string that does not show on the server cached version of the page. When using content matching please ensure that the string you are attempting to match can be found on all versions of the page.