Monitor types and check types
Every monitor in UpAll carries two classifications that look similar and do completely different jobs: the Type label and the Check type. Confusing them is the most common mistake when setting up monitoring, so it's worth being precise.
The type label: organization only
Type describes what kind of thing you're watching: server, network device, internet link, backup, or other. It's purely organizational — a label for keeping a large monitor list readable and for grouping systems in a way that makes sense to your team and your clients.
The type label has zero effect on how the monitor behaves. A "server" and a "backup" with the same check type are probed identically, on the same schedule, with the same rules.
The check type: how probing actually works
Check type is the setting that matters technically. It decides exactly what UpAll sends to the target on every check and what counts as success:
| Check type | What UpAll does | Success means |
|---|---|---|
| HTTP | Requests the target URL, following up to 5 redirects | A response with a status below 400, within 10 seconds |
| Ping | Sends an ICMP echo to the host or IP | An echo reply came back within 10 seconds |
| TCP port | Opens a TCP connection to a specific port (1–65535) | The connection was accepted within 10 seconds |
Once you pick a check type, the Target field unlocks — a URL for HTTP, a hostname or IP for Ping and TCP. Choosing TCP port also reveals the Port field.
Choosing the right check for the target
The rule of thumb: probe as close to the thing users actually consume as you can.
- A website, web application, or HTTP API → HTTP. It exercises the whole stack — DNS, network, web server, application — and an HTTPS target gets automatic certificate watching as a bonus. See HTTP monitors.
- A server, switch, router, or internet link where "is it reachable?" is the question → Ping. It's the lightest probe and works on anything that answers ICMP. See Ping monitors.
- A specific service that isn't a website — a mail server, a database, an RDP host → TCP port. It confirms the actual service is accepting connections, not just that the machine is on. See TCP port monitors.
When two checks could work, prefer the more specific one. Pinging a mail server proves the machine is up; a TCP check on port 25 proves mail can actually be delivered to it. Nothing stops you doing both — a Ping monitor for the host and a TCP monitor for the service — and for critical systems that pairing tells you immediately whether a failure is the machine or the daemon.
The rest of the fields — interval, failure streak, degraded threshold — behave the same for every check type; the walkthrough in Add your first monitor covers them in order.