Uptime and performance monitoring made easy

Schedule new probe

If you have less frequent monitoring and you want to check if your website or service still has errors (and you can't wait until next scheduled run), you can click on "schedule new probe" link as shown below:

This will add your monitoring request to scheduler que, and it will be automatically retested as soon as possible (usually this is in less than 10 seconds, but please note that page auto refreshes every 60 seconds - you may also manually refresh page for quicker result).

Don't have AppBeat account yet? Sign up for Free.

We have switched to BETA 2

In this version of AppBeat we primarily focused on some optimizations of our core monitor service. For example, our core now sends database updates much much efficiently. In each monitoring batch that we dispatch we have several checks. When those checks return result, our dispatcher manager packs all the results into single DataTable and sends it to database as Table-Valued Parameter. This means single roundtrip to database, instead of previously tens of single database updates.

We are close to releasing final version of AppBeat. Stay tuned!

New AppBeat monitoring agents

We have added three new monitoring agents to our AppBeat collection:

  • HTTP header agent: if you want to monitor just HTTP header values from web server, without downloading content, then you should use this agent. This is fastest and most optimal way, to check if your web server is alive.
    Note: your web server must support HTTP HEAD request as described in RFC 2616 protocol, section 9.4.
  • TCP connectivity agent: this is simple agent which checks if TCP port is open or not. For example, you could use this agent to check if RDP port 3389 is waiting for connections. Of course, you can use any port you want. For list of common ports you can check this Wikipedia article: List of TCP and UDP port numbers
  • UDP connectivity agent: similar to TCP connectivity agent, only that it checks UDP ports.

In addition to that, we can also implement private agents, which can monitor your custom solution and are available only to you. If you are interested, please contact us.

Ensuring that correct production version of website is deployed

It is common for web developers to have local "debug" version of website and production version.

For example, in debug version you may have uncompressed, full version of JavaScript files for easier debugging and diagnostics, while in production environment you often deploy smaller and thus faster versions of same files.

To automatically detect situation where you mistakenly published debug version into production environment, you can use free AppBeat account to monitor your web page and alert you of such mistakes. Here is short tutorial how to do this.

Once you are logged-in, click on "Add new check" button which opens "New check" dialog.

On first step simply enter name of your monitor. It is nice to have good name because it will be included in SMS / email notifications:

On second step you enter URL of your page and then click on "Warning" or "Error" tab. Now enter rule similar to this:

In our example we entered warning rule:


When web page from provided URL is downloaded (in our example it is processed first by Error rule, then by Warning rule and finally by Good rule (this is how rules are prioritized). If Error or Warning rules are evaluated to TRUE, notification alert is immediately triggered.

In contrast to Error/Warning rules, Good rule must evaluate to TRUE to be treated as OK. If FALSE is returned it means check is not good and alert is immediately triggered.

If we return again to our rule example:


It simply says that if HTML response from our web server does not contain string it triggers Warning signal and then we are notified about this by SMS or email.

If our web site contains correct (minified) version of AppBeat script (AppBeat.min.js), this rule evaluates to FALSE, which means there is no warning. On the other hand, if we mistakenly publish HTML file which contains link to AppBeat.js, rule would evaluate to TRUE and trigger warning.

This is one simple example on how to effectively use AppBeat in real life. Hope it helps you too!

Improved wizard for adding new checks (monitors)

In latest beta version of AppBeat web app we introduced improved wizard for adding new checks (monitors).

If you keep default names, you can add new website monitor with just three quick actions:

  • click "Next" button on first step
  • enter website URL on second step
  • confirm by clicking "Finish" button

Monitoring your website has never been so easy :) Try it out by signing up for free.

Daily incident report

Today we added new report which can be accessed by clicking "Reports" on left sidebar and then selecting "Incidents by date" tab:

Here you can see for each problematic website or service when did problem start and how long it took until problem was resolved.

Alternatively you can also access this report by clicking date on "Undefined", "Error" or "Warning" section of "Statistics & Logs" (as shown below in green rectangle):

How do I whitelist AppBeat IP in CloudFlare?

If you receive check errors by AppBeat that your website is using CloudFlare which prevents us to scan it, then you will need to whitelist our IP address which is used by our web monitor:

Instructions on how to do this are displayed on CloudFlare Support:

If you have problems please contact CloudFlare support, or contact us for more details by email: contact AT

How to create a status page for your app or website?

Today we turned on new feature in AppBeat web app, called "Public pages". This feature is available for free (if you don't have AppBeat account yet, you can create it here - yes, it is free :)

What are status pages?

Do you have web site or online service and want to add page which displays live status of your service? Something like this?

There are some commercial providers which provide similar pages (usually for monthly fee), but you have to manually update statuses or bother with third party monitoring integration.

With AppBeat this becomes very simple and automated, because we also provide monitoring (All-in-One solution!). Here is how you turn this feature.

After you created your own monitors by clicking "Add new check" button and your "Live status" module displays everything green (status OK), you should click on "Public status" button from left sidebar.

Status pages are by default turned off and you have to click "Enable public status page" to enable it:

When you customized your title and URL you can click second tab: "Services":

Here you must explicitly turn on which services you want to share with your visitors. If you don't like service names or if it has default name "My Monitored App" you can click link "Manage services" which is located under "Other tasks".

That is it! You can check what your users would see by clicking "Show public preview" link. If there is something you don't like just return to AppBeat and edit it again. You can then copy "public preview" link and paste it to your page.

Please note: this is just beginning. We plan to upgrade this feature even further very soon. We will allow you to write your own status updates and comments during service disruptions so your customers will exactly know what is going on.

We will provide you status history and option for scheduled maintenance.

Stay tuned :)

Tip: Azure SQL Database and transient errors

If you are using Azure SQL Database you may occasionally experience following exception (this is example throw by native SqlClient library):

System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.  This failure occurred while attempting to connect to the routing destination.

What is this? 

Azure system may occasionally quickly shift hardware resources to better load-balance various workloads. During this reconfiguration time span, you may have connectivity issues to Azure SQL Database. If this happens, your client can receive transient error (transient fault).

How do you handle this?

 If you are using .NET Framework 4.6.1 or later you can simply update your connection string, without touching your code.

Simply add following to your connection string:

ConnectRetryCount=VALUE1_IN_SECONDS;ConnectRetryInterval=VALUE2_IN_SECONDS;Connection Timeout=VALUE3_IN_SECONDS;

where VALUE1_IN_SECONDS is number between 0 and 255, VALUE2_IN_SECONDS is number between 1 and 60, VALUE3_IN_SECONDS is number between 0 and 2147483647.

It is recommended that you set Connection Timeout to: ConnectRetryCount * ConnectionRetryInterval (in our case VALUE3_IN_SECONDS = VALUE1_IN_SECONDS * VALUE2_IN_SECONDS). It is not recommended to set this value to 0 because this indicates no limit (connect waits indefinitely).