--- title: "Port Monitoring — TCP/UDP Checks for Mail, DB, Game & VPN Servers | FourSight" description: "TCP & UDP port monitoring with banner validation, send/expect regex & presets for SMTP, IMAP, FTP, SSH & DNS. Watch mail, database, game & VPN servers from 4 regions." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Does a port check verify the service is actually working, or just that the port is open?", "acceptedAnswer": { "@type": "Answer", "text": "Your choice per monitor. Connect-only mode verifies the socket opens; banner mode additionally requires the service's greeting to match a regex (an SMTP check expects ^220); send/expect mode transmits a probe string and validates the reply. Banner or send/expect is recommended for production — open ports with dead daemons are a real failure mode." } }, { "@type": "Question", "name": "Can FourSight monitor UDP services?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. UDP checks are supported, including a real DNS query mode for monitoring resolvers on port 53 — the check sends an actual query and requires a valid answer, since bare UDP \"connections\" prove very little." } }, { "@type": "Question", "name": "Is it safe to expose my database port for monitoring?", "acceptedAnswer": { "@type": "Answer", "text": "Don't open a database to the world just to monitor it. Better patterns: allow FourSight's probe regions specifically in your firewall rules, monitor the private listener via an HTTP health endpoint that exercises the DB, or port-check the public-facing pooler/proxy layer that's meant to be reachable." } }, { "@type": "Question", "name": "Can I monitor game servers or custom TCP protocols?", "acceptedAnswer": { "@type": "Answer", "text": "Yes — use the custom preset with any port, then pick connect-only for a basic liveness check or send/expect with your protocol's handshake for real validation. UDP-based game protocols can use UDP mode." } }, { "@type": "Question", "name": "How fast will I know when a port goes down?", "acceptedAnswer": { "@type": "Answer", "text": "Checks run on your monitor's interval — down to 30 seconds on Growth and Pro, 15 seconds on Scale — and an incident opens once a quorum of regions confirms the failure, typically within one to two cycles. Alerts route through email, Slack, webhooks, and escalation policies like every other FourSight check." } } ] }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://foursight.cloud" }, { "@type": "ListItem", "position": 2, "name": "Features", "item": "https://foursight.cloud/#features" }, { "@type": "ListItem", "position": 3, "name": "Port Monitoring", "item": "https://foursight.cloud/features/port-monitoring" } ] } ] --- [FourSight ](/) [Features](/#features)[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq) [Login](/auth)[Start free](/auth?signup=true) [Start free](/auth?signup=true) Port monitoring # Port monitoring for everything that isn't a website FourSight's port monitor opens a real TCP or UDP connection to any host and port from four global regions, then goes beyond "connected": it validates service banners with regex, supports send/expect probes, TLS and STARTTLS, and ships presets for SMTP, POP3, IMAP, FTP, SSH, and DNS. [Start monitoring free](/auth?signup=true) [View pricing](/pricing) A lot of production infrastructure has no URL. Mail servers, databases, game servers, VPN concentrators, SSH bastions, message brokers — if it speaks TCP or UDP but not HTTP, a website checker is blind to it. Port monitoring closes that gap: connect to the socket, verify the service actually answers like itself, and alert when it doesn't. The second half of that sentence matters. A port can accept connections while the service behind it is wedged — the process is alive enough for the TCP handshake but too broken to serve. That's why FourSight validates what the service says, not just whether the socket opens. ## What can you monitor with port checks? Anything with a listening socket. The most common production uses: - Mail infrastructure: SMTP (25/465/587), IMAP (143/993), POP3 — the checks catch a stuck mail daemon hours before users notice missing email - Databases and caches: PostgreSQL (5432), MySQL (3306), Redis (6379), MongoDB (27017) — verify the listener is reachable from outside your network - SSH bastions and jump hosts (22) — banner validation confirms sshd itself is answering, not just the TCP stack - Game servers — players notice within seconds; be ahead of the Discord complaints - VPN endpoints and concentrators — remote workers' access depends on a port most teams never monitor - Message brokers and custom services: RabbitMQ, MQTT, gRPC endpoints, license servers, legacy line-of-business TCP daemons - DNS servers over UDP port 53 — with a real DNS query, not just a connection attempt ## How does banner and send/expect validation work? Most classic protocols announce themselves the moment you connect: an SMTP server says "220", SSH says "SSH-2.0-…", IMAP says "\* OK". FourSight's banner validation reads that greeting and matches it against a regex — so a check only passes when the actual service answers, not merely the operating system's TCP stack. A wedged mail daemon whose port still accepts connections fails the check, which is exactly the failure other monitors miss. For services that speak only when spoken to, send/expect mode transmits a string you define and matches the response against a regex — enough to health-check Redis with a PING, poke a custom line protocol, or validate a proprietary daemon's handshake. TLS and STARTTLS are supported, so implicit-TLS services like IMAPS (993) and opportunistic-TLS setups on SMTP are both first-class. UDP checks are available too, including a real DNS query mode for validating resolvers on port 53. Built-in service presets (all editable) Preset Port / transport Validation SMTP 25 / TCP Banner matches ^220 POP3 110 / TCP Banner matches ^\\+OK IMAP 143 / TCP Banner matches ^\\\* OK IMAPS 993 / TCP + TLS Banner matches ^\\\* OK over TLS FTP 21 / TCP Banner matches ^220 SSH 22 / TCP Banner matches ^SSH- DNS 53 / UDP Real DNS query answered Custom Any / TCP or UDP Connect-only, banner, or send/expect regex ## Why does multi-region port checking matter? Because connectivity is a property of the path, not just the server. A firewall rule change, a cloud security group edit, a BGP hiccup, or an overzealous DDoS mitigation can leave your port reachable from one continent and dead from another — while a single-vantage monitor happily reports green. FourSight probes every port monitor from four regions (US, Canada, Europe, APAC) and requires quorum agreement before opening an incident. That design cuts both ways in your favor: a genuine regional block is visible in the per-region results, while a transient blip on one probe path doesn't page you. For mail servers especially — where an unreachable port silently defers inbound mail rather than bouncing it loudly — region-level visibility is the difference between a five-minute fix and discovering three days of queued email. ## When should I use a port check instead of an HTTP check? Use HTTP checks for anything that speaks HTTP — you get status codes, response-time data, and keyword validation for free. Use port checks for everything else: non-HTTP protocols, or cases where you specifically want to verify the listener layer (is sshd up?) independent of application behavior. The practical pattern for a typical stack: HTTP checks on the app and API, SSL check on the certificate, DNS checks on the records, a port check each on the database, mail, and VPN, heartbeats on the cron jobs, and a domain expiry check on the root — eight monitor types, one dashboard, one escalation policy. All eight unlock together on the Growth plan at $40/mo flat, so covering the non-web half of your infrastructure doesn't require a second tool. **Tip:** Timeouts are configurable per monitor (default 8 seconds). For latency-sensitive services, tighten the timeout so a degraded-but-listening service fails the check instead of limping past it. Included in Growth — $40/mo flat ## Cover the half of your stack that has no URL Port monitoring is included in the Growth plan with all eight check types — TCP and UDP, banner and send/expect validation, presets for the classic protocols, and 4-region quorum before any alert. - TCP and UDP checks against any host and port - Banner regex, send/expect probes, TLS and STARTTLS support - Presets for SMTP, POP3, IMAP, IMAPS, FTP, SSH, and DNS - Per-region connection evidence on every incident [Start free, upgrade when ready](/auth?signup=true)[See Growth plan details](/pricing) FAQ ## Common questions ### Does a port check verify the service is actually working, or just that the port is open? Your choice per monitor. Connect-only mode verifies the socket opens; banner mode additionally requires the service's greeting to match a regex (an SMTP check expects ^220); send/expect mode transmits a probe string and validates the reply. Banner or send/expect is recommended for production — open ports with dead daemons are a real failure mode. ### Can FourSight monitor UDP services? Yes. UDP checks are supported, including a real DNS query mode for monitoring resolvers on port 53 — the check sends an actual query and requires a valid answer, since bare UDP "connections" prove very little. ### Is it safe to expose my database port for monitoring? Don't open a database to the world just to monitor it. Better patterns: allow FourSight's probe regions specifically in your firewall rules, monitor the private listener via an HTTP health endpoint that exercises the DB, or port-check the public-facing pooler/proxy layer that's meant to be reachable. ### Can I monitor game servers or custom TCP protocols? Yes — use the custom preset with any port, then pick connect-only for a basic liveness check or send/expect with your protocol's handshake for real validation. UDP-based game protocols can use UDP mode. ### How fast will I know when a port goes down? Checks run on your monitor's interval — down to 30 seconds on Growth and Pro, 15 seconds on Scale — and an incident opens once a quorum of regions confirms the failure, typically within one to two cycles. Alerts route through email, Slack, webhooks, and escalation policies like every other FourSight check. Keep reading ## Related guides, terms & comparisons - [FourSight pricing — port monitoring unlocks in Growth ($40/mo) ](/pricing) - [Glossary: Port monitor ](/glossary/port-monitor) - [Glossary: Ping monitor ](/glossary/ping-monitor) - [Glossary: Quorum monitoring ](/glossary/quorum-monitoring) - [Feature: DNS monitoring ](/features/dns-monitoring) - [Feature: Cron job & heartbeat monitoring ](/features/cron-job-monitoring) - [Compare: FourSight vs Uptime Kuma ](/compare/uptime-kuma-alternative) - [Compare: FourSight vs Better Stack ](/compare/better-stack-alternative) More check types ## Explore FourSight's other monitors [Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring) ## Start monitoring in under 60 seconds No credit card required. 10 free monitors with 4-region consensus — commercial use allowed. [Start monitoring free](/auth?signup=true) [View pricing](/pricing) FourSight © 2026 [TetraCore](https://tetracorehq.com/). All rights reserved. FourSight is a TetraCore product — Bowling Green, Ohio. Product [Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)[About](/about)[For Agencies](/solutions/agencies)[For Startups](/solutions/startups)[Privacy](/privacy)[Terms](/terms) Features [Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring)[Port Monitoring](/features/port-monitoring) Compare [All comparisons](/compare)[vs UptimeRobot](/compare/uptimerobot-alternative)[vs StatusCake](/compare/statuscake-alternative)[vs Freshping](/compare/freshping-alternative)[vs Pingdom](/compare/pingdom-alternative)[vs Pulsetic](/compare/pulsetic-alternative)[vs Better Stack](/compare/better-stack-alternative)[vs Uptime Kuma](/compare/uptime-kuma-alternative)[vs Cronitor](/compare/cronitor-alternative)[vs Healthchecks.io](/compare/healthchecks-alternative)[vs Hyperping](/compare/hyperping-alternative) Pricing Guides [UptimeRobot Pricing](/compare/uptimerobot-pricing)[StatusCake Pricing](/compare/statuscake-pricing)[Pingdom Pricing](/compare/pingdom-pricing)[Better Stack Pricing](/compare/better-stack-pricing)[Uptime Kuma Pricing](/compare/uptime-kuma-pricing)[Cronitor Pricing](/compare/cronitor-pricing)[Healthchecks.io Pricing](/compare/healthchecks-pricing)[Hyperping Pricing](/compare/hyperping-pricing)[Pulsetic Pricing](/compare/pulsetic-pricing)