Choosing a monitor type

Start from the question you actually want answered.

The one people get wrong

HTTP when they wanted Keyword. An HTTP monitor is satisfied by a 200. Plenty of broken sites return 200 — a blank page, a cached error, a "database unavailable" message rendered by a perfectly healthy web server, a parked domain after a DNS mistake. If you care that the right thing is being served, put a keyword on it and name something that only appears when the page really works.

A few more worth knowing:

Ping when they wanted Port. Huge numbers of hosts and almost every cloud load balancer drop ICMP, so ping fails on things that are working perfectly. If you want to know a service is reachable, check the port it listens on.

Freshness when they wanted Content change. They watch the same date and ask opposite questions. Freshness alerts when something stopped being updated and stays down until it is fixed. Content change alerts once when something did change and never goes down.

API when they wanted HTTP. API behaves identically to HTTP today — there are no JSON assertions yet. Picking it changes nothing about the check.

A monitor when they wanted the agent. Nothing checked from outside can tell you a disk is 95% full. That needs the agent running on the machine.

You can change your mind

A monitor's type can be edited after it is created. The fields change to match, and the history is kept — though be aware that a type change makes the older results mean something different from the newer ones.