Monitor types
Compare Servor monitor types — HTTP, TCP/port, ping, DNS, SSL certificate and keyword — 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 |
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").
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.
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.