Uptime and performance monitoring

Every monitor added to Oh Dear will automatically be checked for uptime. Every time we check the uptime, we also collect and store detailed performance metrics for that website.

Monitor Types

Oh Dear supports three types of monitoring to suit different use cases:

HTTP Monitoring

HTTP monitoring is the most common type and is perfect for monitoring websites and web applications. We send HTTP requests to your website and check for proper responses, response times, and content verification.

Use HTTP monitoring when:

• You want to monitor a website or web application
• You need to verify specific content on a page
• You want to test custom headers or authentication
• You need detailed performance metrics (DNS lookup, connection time, etc.)

Ping (ICMP) Monitoring

Ping monitoring uses ICMP packets to check if a server is reachable on the network level. This is ideal for monitoring servers, network devices, or services where HTTP isn't available.

Use Ping monitoring when:

• You want to monitor server availability at the network level
• You're monitoring non-web services or network devices
• You need basic connectivity checks without application-layer testing
• You want to monitor internal servers or infrastructure

TCP Port Monitoring

TCP port monitoring checks if specific ports are open and accepting connections. This is perfect for monitoring services like databases, mail servers, or any service running on a specific port.

Use TCP port monitoring when:

• You want to monitor specific services (databases, mail servers, etc.)
• You need to check if a particular port is accessible
• You want to verify service-specific protocols with custom strings
• You're monitoring services that don't use HTTP

Multi-location monitoring

Each monitor is checked 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 monitor as down.

This prevents any false alerts.

Uptime options

To check the uptime, we'll send a simple GET request to the monitor you provide. If it responds with a 2xx HTTP response, the check passes. In the settings screen of the monitor, 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 website, you can specify a payload. This payload will be sent along as the form parameters when checking your website.
• request headers: you can specify up to 10 extra HTTP headers that should be used when sending an uptime request to your website.
• redirect URL: you can specify a redirect URL that should be used when checking the uptime of your website. This is useful to verify that your website redirects to a different URL when the uptime check is performed.

Ping (ICMP) Monitoring Options

For ping monitoring, you can configure these settings:

• Ping count: The number of ping packets to send each time we check its uptime.
• Interval between pings: The time to wait between individual ping packets when sending multiple pings.
• Timeout: How long to wait for a ping response before timing out.
• Packet size: The size of each ping packet in bytes.
• Maximum number of hops: The maximum number of hops a packet can make before being discarded.
• Acceptable packet loss: The maximum percentage of packet loss before marking the site as down.
• Acceptable average response time: The maximum average response time in milliseconds before marking the site as down.

TCP Port Monitoring Options

For TCP port monitoring, you can configure several specific settings:

• Timeout: The maximum time to wait for the TCP connection and response in milliseconds (default: 1000ms).
• Look for string in welcome message: An optional string to look for in the server's initial response. If specified and not found, the check will fail. This is useful for verifying specific services (e.g., "220 smtp.gmail.com ESMTP" for SMTP servers).
• Send string: An optional string to send after establishing the TCP connection. You can use \r and \n for line breaks (e.g., "EHLO example.com\r\n" for SMTP).
• Look for string in send string response: An optional string to look for in the server's response to the send string. If specified and not found, the check will fail (e.g., "250-smtp.gmail.com" for SMTP responses).

Verifying response headers (HTTP monitoring only)

When we make a request to your website to verify that it's 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 website 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.

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

If both locations confirm the monitor 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 'Monitors > Settings > Uptime > Notification settings'.

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

What is downtime?

We classify downtime in two 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 monitor settings screen, we consider it down.
3. If the monitor takes more than 5 seconds to load, we consider it down.

Any of those events marks the monitor as unavailable.

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

Detailed reporting

If the monitor 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 monitor 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 information to troubleshoot the problem.

Performance options

You can configure two kinds of alerts regaring performance.

• Hard threshold: if the monitor is continuously slower than this value, we will alert you
• Performance changes: if a website is suddenly this % faster or slower, we will alert you

They both serve their own purpose and will keep you informed on the overall health of your website.

How we detect a sudden change in performance

We look at the difference between the average response time in the past two hours vs average response time in past 15 minutes. Any change faster or slower than the Website performance change notification percentage defined in your website performance settings (e.g. 50%) will trigger an alert.

Your Website performance threshold is your maximum allowable website speed (in milliseconds) before your website is considered slow and alert is sent.

Performance metrics breakdown

We will be able to show you the following detailed metrics.

• DNS lookup: The time it takes to resolve the domain name to an IP address via DNS.
• TCP Connection Time: The time it takes to connect to the remote host (TCP three-way handshake).
• TLS Connection Time: The total time it took for the TLS handshake to complete (cipher negotiation & encryption).
• Remote Server Processing: The time it took the server to process the request and start sending the first byte of the page.
• Content Download: The time, in seconds, it took for the page to be downloaded.

The Time To First Byte (or TTFB) is the same as our Remote Server Processing time.

Monthly reporting

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

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

Here's what that might look like.

Want to know what happened during that month? Click through each monitor 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 monitor settings. This is a great way to monitor websites 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 monitor 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
• Stockholm

Middle East

• Bahrain

South America

• Sao Paulo

US East

• New York

US Central

• Dallas

US West

• Los Angeles
• San Francisco