TCP & Port Monitoring

Monitor any port on any server, globally

Q: What ports can I monitor with UpSec.Watch?

You can monitor any TCP port from 1 to 65535. Common examples include port 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB), 3389 (RDP), 22 (SSH), and custom application ports. If a service listens on a TCP port, we can check it.

Q: Can I monitor database connections remotely?

Yes — TCP monitoring verifies that your database port accepts connections from the outside. We perform a TCP connect check against the host and port you specify, confirming the service is reachable and measuring connection latency. This works for MySQL, PostgreSQL, Redis, MongoDB, and any other database that exposes a TCP port to the network.

Q: What about monitoring SMTP on port 25?

Port 25 (SMTP) is blocked by our edge network for abuse-prevention reasons. If you need to monitor a mail server, consider checking the submission port 587 or SMTPS port 465 instead — both are fully supported. We surface this limitation clearly so you can plan accordingly.

Q: How fast do you detect port failures?

Detection speed depends on your check interval. On paid plans you can check every 60 seconds, so a port failure is detected within one minute. Hobby (free) plans check every 3 minutes. Once a failure is confirmed — after the configurable grace period to avoid flapping — alerts fire instantly via email, Discord, Slack, Telegram, or webhook.

Q: Can I monitor internal or private servers?

Our checks run from a public edge network, so the target host and port must be reachable over the public internet. Private RFC-1918 addresses (10.x, 172.16.x, 192.168.x) and firewalled ports cannot be reached. If your service is behind a firewall, you'll need to allowlist our scanner IP ranges or expose a health-check endpoint.

TCP connect checks for databases, mail servers, game servers, and custom services — probed from 330+ global edge locations with sub-second latency tracking and instant failure alerts.

Start monitoring free See Pricing

330+ edge locations

Multi-channel alerts

1 minute checks

1 asset downCheck asset status below

Total Assets

Monitored

Protected

All checks passing

Down

Failing checks

Reviewing

Active scan

Avg Uptime

99.97%

Last 30 days

Avg Latency

146ms

Fleet average

Security Score

96/100

2 Medium

What's affecting your score2 findings

PassingMedium

Assets

upsec.watch

https://upsec.watch

99.99%

Protected

api.upsec.watch

https://api.upsec.watch

99.97%

Protected

billing-worker

worker:billing-prod

99.94%

Reviewing

404.upsec.watch

https://404.upsec.watch

—

Down

Recent Events

404.upsec.watch12:44 UTC

404.upsec.watch is down (timeout)

api.upsec.watch12:38 UTC

api.upsec.watch recovered

cdn-proxy-0312:22 UTC

cdn-proxy-03 added to monitoring

upsec.watch12:15 UTC

Security scan completed — A grade

billing-worker11:58 UTC

2 medium findings detected

404.upsec.watch11:30 UTC

404.upsec.watch recovered

Domain Discovery

Scanning for subdomains…

Monitoring 7,634 user assets across 330+ edge locations

3 regions1 min cadence365d retention

Any TCP port, any service

MySQL, PostgreSQL, Redis, MongoDB, SSH, RDP, game servers, custom APIs — if it listens on a port, we can check it. Full range from port 1 to 65535.

Global edge probing

Checks run from 330+ edge locations across 9 regions. See exactly where your service is reachable and where it isn't — no blind spots.

Sub-second latency tracking

Every check records TCP connection time in milliseconds. Track latency trends, spot degradation before it becomes an outage, and export historical data.

Universal port coverage

If it listens on a port, we can check it

MySQL, PostgreSQL, Redis, MongoDB, SSH, RDP, game servers, message queues — UpSec.Watch performs real TCP handshakes against any port from 1 to 65535. Not an ICMP ping, not a simulated check. A genuine connection attempt from 330+ global edge locations, measuring real connection latency.

Full TCP handshake — not ICMP ping or simulated checks
Any port 1–65535: databases, caches, message queues, game servers
Connection time measured in milliseconds on every check

port-scan

:5432PostgreSQL12ms

:6379Redis8ms

:27017MongoDB15ms

:22SSH6ms

:25SMTPBlocked

5 services • 4 healthy • 1 blocked

Latency intelligence

Spot degradation before it becomes downtime

Every TCP check records the exact connection time. UpSec.Watch builds a continuous latency profile for each service — so you see the slow creep from 10ms to 50ms to timeout, days before your users file a ticket. Historical charts, daily aggregates, and per-region breakdowns included.

Millisecond-precision connection time on every single check
Per-region latency breakdowns reveal geographic performance gaps
Trend alerts when latency crosses configurable thresholds

latency

TCP Connection LatencyLast 60 min

Multi-region probing

One server, nine perspectives

A service might be reachable from US East but down from Europe. UpSec.Watch probes from up to 9 geographic regions simultaneously — catching network partitions, firewall misconfigurations, and routing issues that single-location monitors will never see.

Simultaneous probes from 9 geographic regions worldwide
Detect network partitions and regional routing failures
Per-region status so you know exactly where the problem is

regions

Region connectivity

US West8ms

US East12ms

EU West45ms

EU East62ms

Asia Pacific128ms

Oceania95ms

Everything you need for TCP monitoring

TCP connect monitoring

Verify that your server accepts connections on the specified port with a real TCP handshake — not just a ping.

Custom port support (1–65535)

Monitor any valid TCP port number. Standard services, high ports, custom applications — no restrictions.

Connection timeout detection

Configurable timeouts per plan (10s–30s) catch hung services that accept connections but never respond.

Response time measurement

Millisecond-precision latency recorded on every check. Spot slow connections before users complain.

Multi-region probing

Paid plans probe from up to 9 global regions simultaneously. Detect regional outages that single-location monitors miss.

Service availability tracking

Uptime percentages calculated from real check data — 24-hour, 30-day, and 365-day windows with daily aggregates.

Configurable check intervals

Check every 1, 3, 5, 15, or 30 minutes depending on your plan. Paid plans support 1-minute intervals for critical services.

Historical latency data

Connection time history with interactive charts. Identify patterns, compare regions, and export data for SLA reporting.

Start monitoring a port in 30 seconds

Enter your host and port

Type the hostname or IP address and the TCP port number you want to monitor. We validate the input and run an instant connectivity test.

Pick regions and intervals

Choose which global regions should probe your service and how often. Free plans use a random edge location; paid plans let you select up to 9 specific regions.

Get alerted on failures

When a connection fails, you're notified within seconds via email, Discord, Slack, Telegram, ntfy, or a custom webhook. Configure grace periods to avoid alert fatigue from transient blips.

65535

Supported ports

330+

Edge locations

<1s

Detection speed

Alert channels

Explore more features

UpSec.Watch combines uptime monitoring with security scanning in one platform.

Website Monitoring

HTTP & HTTPS checks from 330+ global edge locations with instant multi-channel alerts.

Learn more

SSL Certificate Monitoring

Track certificate expiry, chain validity, and protocol downgrades before they impact users.

Learn more

Security Scanning

Automated vulnerability detection — from passive tech-detect to active scanning with thousands of security checks.

Learn more

Frequently asked questions

You can monitor any TCP port from 1 to 65535. Common examples include port 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB), 3389 (RDP), 22 (SSH), and custom application ports. If a service listens on a TCP port, we can check it.

Yes — TCP monitoring verifies that your database port accepts connections from the outside. We perform a TCP connect check against the host and port you specify, confirming the service is reachable and measuring connection latency. This works for MySQL, PostgreSQL, Redis, MongoDB, and any other database that exposes a TCP port to the network.

Port 25 (SMTP) is blocked by our edge network for abuse-prevention reasons. If you need to monitor a mail server, consider checking the submission port 587 or SMTPS port 465 instead — both are fully supported. We surface this limitation clearly so you can plan accordingly.

Detection speed depends on your check interval. On paid plans you can check every 60 seconds, so a port failure is detected within one minute. Hobby (free) plans check every 3 minutes. Once a failure is confirmed — after the configurable grace period to avoid flapping — alerts fire instantly via email, Discord, Slack, Telegram, or webhook.

Our checks run from a public edge network, so the target host and port must be reachable over the public internet. Private RFC-1918 addresses (10.x, 172.16.x, 192.168.x) and firewalled ports cannot be reached. If your service is behind a firewall, you'll need to allowlist our scanner IP ranges or expose a health-check endpoint.