Monthly Archives: February 2014

There is a new “alert contact type” in town: “Web Hooks“.

In its simplest form, “Uptime Robot sends a request to a URL that you mention” with all parameters of the monitor.

After that, you can handle this request and use the information in it for many possible things like sending custom notifications to your clients, restarting servers, integrating Uptime Robot with 3rd party products/services, etc.

Web Hook

It can be used in 2 ways:

  • standard: a standard querystring is added to the end of the Web Hook alert contact
  • custom: a totally custom querystring structure can be created with the variables provided

As an example:

If a web-hook alert contact is http://www.domain.com/?, Uptime Robot will send a notification like http://www.domain.com/?monitorID=95987545252&monitorURL=http://test.com&monitorFriendlyName=Test Website&alertType=*0&alertDetails=Connection Timeout&monitorAlertContacts=457;2;[email protected].

Or, a custom Web Hook can be created like http://www.domain.com/?id=*monitorID*&type=*alertType* by simply using the variables wrapped inside ** characters.

These variables can be found in the “Create New Alert Contact” dialog in “My Settings page”.

Hope that it can simplify any possible integrations.

It is already possible to monitor websites that require “HTTP basic auth” with Uptime Robot by providing login details.

However, it was not possible to monitor authentication-required websites without providing the auth credentials as Uptime Robot was considering any HTTP 401 response as “down”.

A logic update is applied today that will count HTTP 401 as:

  • “up” if no authentication info is provided
  • “down” if authentication info in provided

Simply, you can now monitor auth-required websites without providing these details.

With the new version of Uptime Robot’s front-end, response time data was also added as a new feature.

However, it was not available in the API until today as we were experimenting ways to keep this huge data. Things look pretty stable now and response times can now be reached via API.

As expected, the feature is a parameter for the getMonitors method. There are actually 2 parameters:

  • responseTimes: if set to 1 (responseTimes=1), the response time for all the checks in the last 24 hours is returned
  • responseTimesAverage (optional): the API can also return the values as averages for given minutes (for ex: the dashboard averages the values as 30 minutes). This parameter will be very handy once the data for longer periods will be available and we’ll be able to get averages for hours/days/weeks, etc.

Hope that this new addition will enable you to provide more useful data in your site and/or apps.