TCP & UDP Monitoring

TCP and UDP monitors check raw port connectivity — useful for databases, mail servers, DNS, and any service that isn't HTTP-based.

TCP Monitoring

TCP monitoring opens a raw connection to host:port and checks that the connection succeeds within the timeout.

Create a TCP monitor

Field	Example	Notes
Host	db.yourapp.com	Hostname or IP address
Port	5432	Port number
Timeout	5000	Connection timeout in ms

Common TCP use cases

Service	Port
PostgreSQL	5432
MySQL / MariaDB	3306
MongoDB	27017
Redis	6379
Elasticsearch	9200
RabbitMQ	5672
SMTP	25, 587, 465
IMAP	993
SSH	22
Custom TCP services	Any

Send/expect (optional)

For protocols that respond to a greeting, you can send a string and check the response:

type: tcp
host: mail.yourapp.com
port: 25
send: "EHLO alertifypro.com\r\n"
expect: "250"       # Response must start with 250 (SMTP OK)

---

UDP Monitoring

UDP monitoring sends a UDP packet and checks for a response.

note

UDP is connectionless — not all services respond to UDP probes. Test manually first.

Common UDP use cases

Service	Port
DNS	53
NTP	123
SNMP	161
Syslog	514
Game servers	Custom

Configuration

type: udp
host: dns.yourapp.com
port: 53
payload: "Hello"         # Bytes to send (hex or ASCII)
expect: "response"       # Expected response string
timeout: 5000

---

Alerting on TCP/UDP

Alert rules work the same as HTTP monitors:

alert_policy:
  consecutive_failures: 2
  severity: critical
  notify: [slack, pagerduty]

TCP/UDP monitors also report connection time (latency), and you can alert on slow connections:

assert:
  connection_time_ms: { lt: 500 }   # Alert if connection takes >500ms

---

Monitoring internal services

If your database is on a private network, use a private probe:

1. Deploy the AlertifyPro probe agent inside your private network
2. Assign your TCP monitor to use the private probe
3. The probe checks internal services and reports back via encrypted tunnel

Private probes →