Skip to content

Test connection

The monitor form has a Test connection button that probes the target immediately, using exactly what's in the form at that moment — check type, target, and port if it's a TCP check. Nothing needs to be saved first, and nothing is saved by testing: it's a one-off probe whose result you see on the spot.

What it returns

The test behaves like a real scheduled check, so its result is the real verdict:

  • Success — confirmation plus the response time in milliseconds, the same measurement a scheduled check would have recorded.
  • Failure — the exact error the probe hit, not a generic "failed": a hostname that doesn't resolve, a refused connection, a timeout, an HTTP error status. It's the same text a real check would log as the failure reason.

That precision is the point. "Connection refused" on a TCP check says the host is reachable but nothing is listening on that port — probably the wrong port number. A DNS error says the target itself is mistyped. A timeout points at a firewall or a down host. You can diagnose and fix the field right there, then press the button again.

Why saving isn't needed

Without a pre-save probe you'd have to save, wait for the schedule to run the first checks, and come back to find out whether the monitor was ever valid. A misconfigured monitor is worse than none: it fails permanently, opens an incident about a system that's fine, and emails your whole team. Test connection closes that loop before it starts — the walkthrough in Add your first monitor uses it as a standard step before saving.

Limits

  • Rate limit: 10 tests per minute. Enough for normal editing and troubleshooting; hit it and you wait briefly. Scheduled checks are unaffected.
  • Refused targets. The test declines loopback addresses (like 127.0.0.1), link-local addresses, and malformed targets that aren't a valid URL, hostname, or IP. Checks run from UpAll's infrastructure, so a loopback or link-local target could never point at your systems — it would point inside the monitoring platform itself. If your target is only reachable from inside a private network, UpAll's probes can't reach it either way; monitor something on the boundary instead — the public interface, the VPN endpoint, the firewall.

What a passing test does — and doesn't — mean

A successful test proves the target is checkable from UpAll right now: name resolution works, the path is open, something answered. It's a snapshot, not a warranty — continuous confirmation is what the monitor itself provides once saved. If the test succeeds but you're unsure the right thing answered, compare the response time against expectations, or aim a more specific check at the service; see Monitor types and check types.