For services that don't speak HTTP
TCP and Ping monitoring
A lot of what keeps a site running isn't the site itself. A database, a mail server, a queue passing messages between two applications: services working below the surface, and completely out of reach for an HTTP check.
In short
- TCP: opens a real connection to a host and a port, the specific access point of a service on that machine, and measures response time
- Ping: checks that the host is reachable on the network, with no specific port involved
- Monitorable ports always stay within your package's allowlist
- Useful for databases, queues, mail servers and anything with no web interface
What it actually checks
The TCP monitor opens a real connection to the host and port you specify, and measures how long it takes to respond. No scanning, no arbitrary payloads: just the port you chose. The Ping monitor works at an even more basic level, checking whether the host is reachable on the network, before any question of specific ports or services comes into play.
A concrete case
A small practice has a booking app that talks to a database on a dedicated port. A server update changes a firewall rule and that port stops answering. The storefront in front of it stays perfectly online, an HTTP check wouldn't see anything wrong, and it's only discovered when a client calls because they can't book. The same thing happens, at scale, behind every site an agency manages: a database, a queue, a dedicated mail server, none of which ever come up in conversation until they break.
Self-service or assisted setup
If you don't know the exact port to check, or you're not sure which service behind the site is actually worth monitoring, we can work it out together: just the server's address and a description of what runs behind it, and we'll decide the rest during assisted setup.
Not sure which port to monitor? Let's check it together.
Contact