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 aPOST
,PATCH
orPUT
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.
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.
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.
What is downtime?
We classify downtime in 2 ways:
- If we receive anything other than an
HTTP/2xx
response code on the check page, we consider it down. Note that we will followHTTP/301
andHTTP/302
redirects. The final result of the redirect should be anHTTP/2xx
. - 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. - 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
Feel free to reach out via [email protected] or on Twitter via @OhDearApp if you have any other questions. We'd love to help!