Monitor types
Compare Servor monitor types — HTTP, TCP/port, ping, DNS, SSL certificate, keyword, heartbeat, agent metric — and learn which one to use for each service.
Servor offers several monitor types, each built to check a different layer of your infrastructure. Picking the right type is the difference between a monitor that catches real problems and one that cries wolf. This page explains each type and when to reach for it.
New to monitoring? Start with create a monitor — you choose the type there.
The types at a glance
| Type | Checks | Best for |
|---|---|---|
| HTTP(S) | A URL responds with an expected status code | Websites, APIs, web apps |
| TCP / port | A TCP port accepts a connection | Databases, SSH, mail, game servers |
| Ping (ICMP) | A host replies to ping | Basic host reachability |
| DNS | A domain resolves to the expected record | Domains, DNS migrations |
| SSL certificate | A certificate is valid and not expiring soon | HTTPS sites, avoiding expiry outages |
| Keyword | A page contains (or is missing) a given text | Detecting error pages, defacement, content |
| Heartbeat (push) | Your job calls us — the silence is what alerts | Cron jobs, backups, imports, scheduled work |
| Agent metric | A threshold on the CPU, RAM, swap, disk or load already reported | Watching resources without running any command |
HTTP(S)
The most common type. Servor sends an HTTP or HTTPS request to a URL and checks the response. Use it for anything that speaks HTTP — a marketing site, a dashboard, a REST API, a health-check endpoint.
A good HTTP monitor points at a cheap, meaningful URL. A dedicated /health endpoint that touches your database is far more useful than the homepage, because it fails when the thing that matters fails.
Point at a health endpoint
If your app has a /health or /status route, monitor that. It returns fast, stays
stable, and reflects whether the app can actually do its job.
TCP / port
Checks that a given port accepts a TCP connection on a host — without speaking the protocol on top of it. Use it for services that aren't HTTP: a PostgreSQL or MySQL database (5432 / 3306), SSH (22), SMTP (25 / 587), Redis (6379), or a game server.
A TCP monitor tells you the service is listening. It won't tell you it's healthy inside — for that, prefer an HTTP or keyword check when the service supports one.
Ping (ICMP)
Sends an ICMP echo (a "ping") and waits for a reply. It's the lightest reachability check: is the host up and reachable on the network at all? Use it as a coarse signal for a machine or network device.
Ping can be blocked
Many hosts and firewalls drop ICMP on purpose, which makes a healthy server look down to a ping monitor. If a host blocks ping, monitor a real service on it (HTTP or TCP) instead.
DNS
Resolves a domain and checks it returns the record you expect. Use it to catch DNS problems directly — a record that disappeared, a bad propagation after a change, or a registrar issue. It's especially handy during a DNS migration or a custom domain setup, where you want to confirm the new record is live everywhere.
SSL certificate
Checks that the certificate served on an HTTPS host is valid and not about to expire. Expired certificates are one of the most common and most avoidable outages — a certificate silently lapses and every visitor gets a browser warning.
An SSL monitor warns you ahead of expiry so you can renew in time. Add one for every HTTPS domain you care about, including your status page custom domain.
Keyword
Fetches a page and checks whether a specific piece of text is present (or absent). This catches failures a status code misses: a page that returns 200 OK but shows an error message, a maintenance banner, or a blank/defaced page.
Common patterns:
- Must contain a word you expect on a healthy page (e.g. your product name,
"Sign in"). - Must not contain an error string (e.g.
"500","Service Unavailable","Under maintenance").
Checking a JSON field
When the endpoint answers in JSON, raw text is a blunt instrument: "ok" may well
appear somewhere else in the response. Give a JSON field and the expected
value instead — the status field equal to healthy, say, or services[0].state
equal to up.
The syntax takes dotted keys and numeric indexes (data.checks[2].name). It is
deliberately limited: there are no wildcards and no filters, because a path that
matches nothing should fail outright rather than quietly assert something else. If
the response is not valid JSON, or the field is missing, the monitor goes down.
Heartbeat (push)
The one monitor that probes nothing. Every other type asks a question and reads an answer; this one waits for a call. Your job — a cron, a backup, a nightly import — calls a private URL when it finishes. As long as the call keeps arriving the monitor stays green; once the silence exceeds the window you set, the alert fires.
It is the only way to catch this kind of failure. When a scheduled job quietly stops running, nothing goes down: no port closes, no page returns an error, and every other check on the machine stays green.
When you create the monitor, Servor shows you the line to add at the end of your job:
curl -fsS -m 10 https://api.servor.app/public/heartbeat/YOUR_TOKEN
The flags matter: -f fails the command on an HTTP error, -sS stays quiet on
success (so cron does not mail you on every run) while still printing real errors,
and -m 10 keeps a hanging request from delaying the job it is attached to.
This URL is a secret
The token in it is the only thing protecting this monitor. Anyone holding it can report the job as healthy — which would leave you believing a backup is running after it stopped. Do not commit it to a public repository.
A monitor that has never been called counts as down, not "unknown": from the moment it exists, the job it stands for is supposed to be calling.
Agent metric
A threshold on a value the agent already reports: CPU, RAM, swap, disk space or load average. It is the only check that runs no command at all on the machine — it reads the sample that arrived seconds ago.
That changes two things. It costs nothing: where a disk monitor runs df, this one looks
at a row already in the database. And it keeps working when the machine is too loaded to
fork a shell — which is exactly when you want to hear about it.
Thresholds are numbers, not percentages, because load average is not one: a load of 4 saturates a four-core box and leaves a thirty-two-core box idle. For CPU, RAM, swap and disk that number reads naturally as a percentage; for load, it is the load.
A stale reading counts as an outage
If the agent has stopped reporting, the check goes down rather than judging on the last known value. A silent agent is a real problem, and treating its last sample as current would hide precisely the incident that matters. The tolerance is five minutes.
Which type should I use?
- A website or API → HTTP(S), ideally on a health endpoint.
- A page that can return 200 but still be broken → add a keyword monitor.
- A database, SSH, mail or other non-HTTP service → TCP / port.
- Just "is the machine reachable?" → ping (unless ICMP is blocked).
- A domain or DNS change → DNS.
- Any HTTPS certificate → SSL certificate, to head off expiry.
- A machine's CPU, RAM, swap, disk or load → agent metric: nothing to run, and it still alerts when the box is saturated.
It's normal to run several types on the same service — for example an HTTP monitor for the app, an SSL monitor for its certificate, and a TCP monitor for its database. Once you've picked a type, create the monitor in Servor.