Docs/Features

Uptime monitoring

Every site that gets added to Oh Dear will automatically have its uptime monitored.

Multi-location monitoring

Each site is monitored from a primary location and verified from a secondary location. You can choose your primary location from within the Oh Dear dashboard.

If the primary location reports an error to Oh Dear, the secondary location is used to verify the problem. We'll only trigger an alert if both the primary and the secondary checks report the site as down.

This prevents any false alerts.

Uptime check options

To check the uptime, we'll send a simple GET request to the site you provide. If it responds with a 2xx HTTP response, the check passes. In the settings screen of the site, there are several options available to customize this check:

  • look for string: we can check if a given string is found on the result. If it is not found, we'll mark the check as failed. This is sometimes called a "check string" or "HTML verification".
  • absent string: we can check if a given string is not present on the result. If it is found, we'll mark the check as failed..
  • response headers: you can configure the uptime check to verify the values of certain headers on the response.
  • http verb: instead of a GET request, you can specify that the check should be performed with a POST, PATCH or PUT HTTP method.
  • payload: when not using a GET request to check your site, you can specify a payload. This payload will be sent along as the form parameters when checking your site.
  • request headers: you can specify up to 10 extra HTTP headers that should be used when sending an uptime request to your site.

Verifying response headers

When we make a request to your site to verify that your site is up, the response of your server will contain certain headers. We can verify that those headers contain the values you expect. If these expectations are not met, we'll consider your site as down.

In the "Responses" section of the uptime settings page, you can specify which headers we should verify.

You could add this expectation to ensure your page uses gzip compression.

image

If you want to verify that a particular header is set on the response, regardless of its value, you can use the "matches pattern" condition and the * wildcard as the value. In this example, we'll verify that the response contains a header named laravel-responsecache with any value.

image

Check frequency

Uptime checks happen every minute from the primary location.

As soon as the primary location detects a problem, the secondary location will be used to verify it.

If you were to put this on a timeline, it would look like this.

Time Status Monitored via
15:20h OK Primary location
15:21h OK Primary location
15:22h PROBLEM Primary location
15:22h PROBLEM + Secondary location
15:23h PROBLEM Primary location
15:23h PROBLEM + Secondary location
15:24h PROBLEM Primary location
15:24h PROBLEM + Secondary location
15:24h Notification fired: site DOWN
15:25h PROBLEM Primary location
15:25h PROBLEM + Secondary location
15:26h OK Primary location
15:26h Notification fired: site UP
15:27h OK Primary location
15:28h OK Primary location

The first problem is detected at 15:22h and the second location is immediately used to confirm the problem.

If both locations confirm the site is down for 2 minutes in a row, you will be notified of this event. If this is too quick you can increase the number of downtime minutes before a notification in ‘Site > Settings > Uptime > Notification settings’.

The check at 15:26h confirmed the site was back online, so you'll be notified of that too.

Note: choose when you are alerted
You can overwrite the behaviour for when we alert you, by changing the site settings in your dashboard.

What is downtime?

We classify downtime in 2 ways:

  1. If we receive anything other than an HTTP/2xx response code on the check page, we consider it down. Note that we will follow HTTP/301 and HTTP/302 redirects. The final result of the redirect should be an HTTP/2xx.
  2. If we receive a HTTP/2xx response, but we didn't find the optional check string specified on the site settings screen, we consider it down.
  3. If the site takes more than 5 seconds to load, we consider it down.

Any of those events marks the site as unavailable.

For example, an HTTP/204 No Content response will also be considered "online".

Detailed reporting

If the site took too long to load, we can only show you that it timed out.

Operation timed out after 5000 milliseconds with 0 bytes received

However, if the site responded with a status code other than HTTP/200, we will show you the exact HTTP response headers we received to help you troubleshoot, along with the IP(s) we used to monitor your site.

Downtime is verified from multiple locations, those locations and their IP addresses are confirmed in the notification:

Monitored from: Paris, France (45.32.146.84, 2001:19f0:6801:5f3:5400:1ff:fe38:3572)
Verified downtime via: Chicago, USA (104.207.138.202, 2001:19f0:5c01:7c0:5400:1ff:fe38:72f1)

All debug-headers are supplied for you, together with copy/paste cURL commands for you to replicate our exact check.

$ curl -i https://yoursite.tld
HTTP/1.1 500 Internal Server Error
Date: Sun, 03 Dec 2017 16:05:11 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: ...

With that information, you should have all the needed information to troubleshoot the problem.

Monthly reporting

Each month, you'll receive an uptime report for all your sites to show you how well they performed.

In it, we show you what percentage of uptime each site received, as monitored via its primary location. If a site is down, it'll be subtracted from the total uptime.

Here's what that might look like.

Site Uptime
ohdear.app 100%
ourcompetitor.io 99.95%
hackerne.ws 100%

Want to know what happened during that month? Click through each site and navigate to the uptime page in the Oh Dear dashboard to see the timings of each downtime.

Adding custom headers

You can add custom headers through your site settings. This is a great way to monitor sites behind basic authentication.

Here's an example of adding custom headers for such a setup: https://ohdear.app/blog/how-to-monitor-websites-behind-http-basic-authentication

Monitoring uptime of authenticated pages

Yes, you can add custom headers to authenticate Oh Dear to your application through your site settings.

Here's an example of adding custom headers for such a setup: https://ohdear.app/blog/how-to-monitor-websites-behind-http-basic-authentication

Our monitoring locations

We perform uptime checks from these locations:

Africa

  • Cape Town

Asia

  • Bangalore
  • Seoul
  • Singapore
  • Tokyo

Australia

  • Sydney

Canada

  • Toronto

Europe

  • Frankfurt
  • London
  • Paris

Middle East

  • Bahrain

South America

  • Sao Paulo

US East

  • New York

US Central

  • Dallas

US West

  • Los Angeles
  • San Francisco
Was this page helpful?

Feel free to reach out via support@ohdear.app or on Twitter via @OhDearApp if you have any other questions. We'd love to help!