What can you monitor besides websites?

Oh Dear can do more than just monitor websites. We focus on monitoring HTTP and HTTPS endpoints, and in today's world - that is quite a lot!

Websites and blogs

The most obvious to monitor are websites, blogs, webshops, product pages, personal homepages, company sites, ...

These are the pages you normally think of that need monitoring. You can add any website to Oh Dear, and we'll monitor its uptime, SSL certificates and broken links.

API endpoints

We can also monitor API endpoints. We can perform a GET, POST, PATCH or PUT call to whichever endpoint you have.

You can allow our IPs or add HTTP Basic Authorization headers to provide us access to otherwise protected resources.

You can monitor specific endpoints too, by supplying additional HTTP payloads to the API call we perform. This can a JSON body to a REST API or a simple HTTP FORM submission.

You could test the product-information retrieval, validate user logins, check order submissions, ... all via custom HTTP payloads and headers.

JSON and XML response validation

Every uptime check can optionally have the "look for string" option enabled. You can use this option to validate JSON responses, by asserting a certain structure or keyword is present in the response.

This option will force us to look at the body response of a check and make sure that a particuler string is present in the response. This string can be plain text, HTML tags, XML, JSON, ...

S3 buckets and files

Both public and private S3 buckets can be monitored by us. For public buckets, add the bucket URL (or a particular file) to Oh Dear and we'll verify if always returns an HTTP/200 response.

For private buckets, you can add a custom authentication header to allow us to fetch and validate the response.

WebDAV and CardDAV

Both WebDAV and CardDAV are extensions of the HTTP protocol. They add additional functionality on top of HTTP/HTTPS, and we can monitor that just like it's any other website.

You can add the URL of your WebDAV or CardDAV endpoint to Oh Dear, and we'll check for uptime, SSL certificates and everything else.

In most cases, you can add the base URL of the WebDAV or CardDAV system to Oh Dear, as that supports GET requests.

Websockets over HTTPS

Websockets may be a TCP protocol, the initial handshake often happens via HTTP or HTTPS.

You can add your Websocket endpoint to Oh Dear as if it was any other website. You may include the Websocket port, if it's running on a non-standard port.

For instance, the following is a valid Websocket URL for monitoring: https://socket.ohdear.app.

By adding the Websocket destination as an HTTPS site, we can monitor the certificate expiration date and check its uptime.

Websites on custom ports

If you have a website running on a custom port, you may add it to Oh Dear using the standard port-notation.

For instance: https://yoursite.tld:8001

This example would monitor your site on port 8001.

Full website health checks

Your website is most likely a combination of PHP/Ruby/Perl, a database (MySQL, PostgreSQL, MSSQL) and queues (Redis, RabbitMQ, Memcached).

You can add healthcheck endpoints to your website, like yoursite.tld/healthcheck, that validates the healthy state of each of those services.

Do your queues always need less than 100 items in them? If you add a bit of custom logic to the /healthcheck endpoint, you can return an error whenever your limit is reached. Oh Dear can pick that up and notify you. You could add the health of your entire application in a single HTTPS endpoint.

To make sure this information remains hidden, you can limit access to the Oh Dear IP addresses or add a custom HTTP header for authentication.

As an additional benefit, it allows you to programmatically control the healthchecks of your application, directly in your application and in your current version control.

This technique allows you to expose internal metrics and use Oh Dear for the notification of problems that would otherwise remain hidden.

Cron jobs and scheduled tasks

Every Oh Dear client has the ability to monitor cron jobs and scheduled tasks, both from Linux and Windows servers.

Each cron job is given a unique URL endpoint that should be called whenever the job completes. If we don't receive that ping back to us, we know the cron job hasn't run, and we can inform you about it.

For more details, have a look at our cron job monitoring documentation.

Jobs and background workers

The same technique that is used by the cron job monitoring can be used to monitor background processes or jobs.

This way, you can fully test and monitor your background processes.

To do this, create a new cron job definition to monitor, under any of your sites. You'll be given the ping URL in return. Instead of adding this to the cron job of your choice, add it as the very last step in the processing of your queued jobs or worker processes.

Every time that worker stops, or finishes a current task, it can call back to us and we can notify you if we stop receiving such a heartbeat.