The first time one of our users added a monitor, the form asked about the monitor type and showed four options to choose from. The user picked the first one on the list, because it sounded the most like a website - and that happened to be the right choice. They never used the other types and for the next few months had no idea what the remaining ones were for.

It turned out later that two of them solve problems the user did not even know they had.

So, one at a time and without the technical jargon: what each monitor type actually checks, what the other three will not see, and when it is worth switching on at all.

First, one thing that puts the whole picture in order

The monitor types are four different things you can check, not four levels of thoroughness of the same thing. It is not the case that one is better than another.

  • HTTP(s) status - checks your website.
  • DNS - checks whether your domain and your mail point where they should.
  • Port (TCP) - checks devices and services that are not a website: a server, a NAS, mail.
  • API (JSON) - checks whether your service's technical response still has the same structure.

There is one more thing that confused our user for a while: SSL certificate monitoring, the health audit and content monitoring are not separate monitor types, but add-ons you switch on inside an HTTP monitor. So do not look for them in the list of types - they are further down the form, in the „what else we watch" section.

One last note before you start: the monitor type cannot be changed once saved. That is not a problem, because you can always add another one, but it is worth knowing before you click „Add".

1. HTTP(s) status, the one everybody starts with

This is the monitor for a website, and for the vast majority of people it will be the only one they really need at the start.

It works by fetching your page at a set interval, exactly the way a visitor's browser would, and grading what it got back: whether the server responded at all, whether the response is correct, how long it took and whether the certificate is in order. All you give it is an address, the same one you type into your browser.

You can add three things to this monitor, and this is where it becomes something more than a check of „does it open":

  • SSL certificate monitoring - watches the padlock next to your address and warns you 30, 14 and 7 days before it expires. Worth switching on every time, it costs one click.
  • Site health monitoring - a daily audit that compares today's state of the page with yesterday's and tells you if something got worse. This is the feature that catches the fact that after an update your site stopped being visible in Google, or became twice as slow.
  • Content monitoring - checks whether text that should be on the page is there, or whether text that should not be there has appeared.

That last one sounds odd until you understand what it is for. A server can politely answer „everything is fine" and serve a page with an error message or no content at all. To a plain availability check the site is working. To a visitor it is not.

When NOT to use it: for things that are not a website. A NAS login panel or a mail server can be checked over HTTP, but it usually ends in false alarms. That is what the port monitor is for.

Example. The owner of a small online shop has three monitors of this type: the homepage, a product category and the cart. The cart is separate for a reason - the homepage usually loads from cache and works even when the database is struggling, while the cart hits the database on every visit. On the cart she has content monitoring enabled with the phrase „Add to cart". When a plugin update made the button disappear while the page still loaded normally, she got an alert within five minutes. Without it she would have found out from a customer asking why nothing can be bought - the next day at best.

Another example. A site owner hired an agency to improve the site's ranking for selected phrases. Those phrases were added to the page content at the agency's request. The agency then set up monitoring for that page to be sure that the four phrases that mattered were actually present at that specific URL. Two weeks later another person working on the site came back from holiday, edited the content and removed two of the four phrases along the way. The SEO agency, notified about the missing phrases, was able to react quickly.

2. DNS, or making sure your domain points where it should

For the user mentioned earlier this was discovery number one. For years they had no idea this was something you could monitor at all.

A domain is not just the address of your website. Attached to it is also information about where your mail should go, who may issue a certificate for it and whether your messages land in the inbox or in the spam folder. This information is called DNS records, and it is usually set once and then forgotten.

The problem is that these records can disappear or be changed - by the hosting provider, the domain registrar, the previous company that looked after the site, or by you during a clean-up. And worst of all, none of it is visible. The site works, the admin panel works, and the mail simply stops arriving.

A DNS monitor asks the servers about a chosen record of your domain and compares the answer with what you expect. Everything in the form is described in plain language, so you do not need to know what the abbreviations mean:

  • Site address (A) - the server your visitors land on.
  • Mail server (MX) - where messages sent to your address end up.
  • Text record (TXT) - among other things, the setting that decides whether your e-mails go to spam.
  • Name servers (NS) - who manages your domain's records in the first place.

You also choose how the answer is compared. For everyday watching, „the value must be present" is enough. The „exactly these values" option is stricter: it will also raise an alarm when somebody adds something to your domain, which is often the first sign that somebody is tampering with it.

One practical detail: DNS records are remembered by servers for tens of minutes, so checking them every minute makes no sense. The app warns you about this itself. Once every fifteen minutes or once an hour is perfectly sufficient.

When NOT to use it: if your domain and your mail live in one place, nobody but you has access to the domain panel and you are not planning any move, the risk is small. But a monitor on your mail server takes five minutes to set up, so it is worth switching on anyway.

Example. A service company moved its mail to a different server. The person doing it fixed the mail record but deleted the text record responsible for sender verification along the way. For two weeks the offers sent to clients landed in spam, while inside the company the prevailing belief was that „clients have not been replying much lately". A DNS monitor on that record would have flagged it the same day. After that episode they have three monitors: the site address, the mail server and the text record, all checked every half hour.

3. Port (TCP), or checking things that are not a website

This type looks the most technical and is probably the easiest to understand. You provide the device's address and a port number, and the monitor simply tries to connect and measures how long it took. Connection made - it works. No connection - an alert.

A port is the number of the „door" a given service is listening behind. You do not need to know which number is the right one - the device's documentation, or whoever configured it, will tell you.

What this is useful for in everyday life:

  • a NAS or network drive in the office, where you keep backups and documents,
  • a mail server, if you run your own,
  • a computer or server in the office that you connect to remotely,
  • a till, a label printer, a CCTV recorder and other devices that have to be reachable on the network.

This monitor has one clear advantage over checking such a device's panel over HTTP: the web interfaces of NAS boxes and similar hardware can be slow to wake up and produce false alarms even though the device was working the whole time. A port connection answers immediately, so the alerts are real.

It is worth knowing what it does not check: it does not grade what the service returns. It only knows that something answered at that address and port. For checking the contents of a page, there is the HTTP monitor.

When NOT to use it: for an ordinary website. It will tell you the server is alive, but not that the page is showing an error.

Example. A small design studio keeps all of its files on a NAS in the office and backs up everyone's computers to it every night. At one point the NAS shut down after a power cut and nobody noticed for eleven days, because during the day everyone worked locally anyway. The backups simply were not being made. They now have a port monitor checking the NAS every five minutes and an alert on their phones. It is no longer about the device itself, but about being sure the backups have somewhere to go.

4. API (JSON), the technical one

If you are not sure whether you need it, you almost certainly do not - and that is perfectly fine. This type is for people who have something in their service that is technically called an API.

In plain terms: some sites and applications pull data from a separate address that returns not a page to look at, but raw data to process. A price list, available appointment slots, stock levels, a list of offers. The site itself works, but if that address stops returning data in the expected shape, part of the service stops working.

The API monitor records the structure of the response, meaning which pieces of information are in it, and then watches whether they are still there. It deliberately does not compare values: a changed price or title is a normal thing, while a field that vanished entirely is a failure. Setting it up is friendlier than it sounds - you provide the address, click „Fetch and analyse", and the app shows you the list of fields and asks which ones to watch.

When NOT to use it: for an ordinary company website, a shop on an off-the-shelf platform or a blog. There is nothing there for this monitor to watch, and an HTTP monitor with content monitoring will do the job better.

Example. A booking site pulls available slots from an external system. After an update to that system, one of the fields was renamed. The booking form still displayed, only the calendar was empty, so to everybody - including availability monitoring - the site looked normal. It was reported two days later by a customer asking whether they were closed. An API monitor catches exactly this situation, because it sees that a field which used to be in the response has disappeared.

Bonus: a monitor whose job is to make sure something does NOT work

Every monitor has an „Expected state" field, set to „Should be available" by default. The second option reverses the whole meaning of the monitor: the alert arrives when the address starts responding.

That sounds absurd until you think about things that are supposed to be closed off: a test version of a site, an admin panel reachable only from the company address, an office camera. If such a place suddenly starts answering the whole world, it means the protection has stopped working - and it is better to hear that from your monitoring than from somebody else entirely.

So where to start

Back to the user from the beginning of this article: today they have four monitors instead of one, and none of them exists because it seemed like the done thing. Each one was created after some incident they would rather have known about sooner.

The order we would suggest looks like this:

  1. An HTTP monitor on the homepage, with certificate monitoring enabled. This is the absolute basic.
  2. A second HTTP monitor on the place that really matters to you - the cart, the contact form, the offer page.
  3. A DNS monitor on your mail, because mail disappearing quietly is one of the most expensive failures that can happen to you.
  4. A port monitor, if you have a NAS or another device in the office that you care about.
  5. An API monitor only once somebody technical tells you there is something in your service worth watching this way.

Four types sound like a lot of choice, but in practice it comes down to a single question: what exactly do I want to check - a website, a domain, a device or data. The rest follows on its own.