At 2:47 AM on a Saturday, an e-commerce platform's checkout flow silently broke. The frontend worked. The API responded. The load balancers were healthy. But zero transactions were completing.
The culprit? Their PostgreSQL database port had stopped accepting connections after a botched security group update. The database was running. The server was up. But port 5432 was unreachable.
By the time someone checked Twitter and noticed customer complaints, they'd lost $43,000 in sales and dozens of angry 1-star reviews.
The brutal truth: most monitoring tools only check if your web pages load—they completely ignore the critical ports your application depends on.
This guide shows you how to monitor database ports, API endpoints, custom services, and any TCP/UDP port so you catch failures before they cascade into customer-facing disasters.
Why Port Monitoring Matters More Than You Think
Your application is only as reliable as its weakest dependency. A dead database port means:
- Silent failures. Your app might return 500 errors or timeouts while looking "up" to basic monitors.
- Cascading outages. One blocked port can take down multiple services that depend on it.
- Lost revenue. Every minute your database is unreachable is money walking out the door.
- Reputation damage. Users remember outages more than they remember uptime.
- Compliance violations. SLA breaches, audit failures, and regulatory penalties.
And here's the kicker: most of these issues are completely preventable if you're actively monitoring the ports your services actually use.
What Port Monitoring Actually Checks
Unlike simple HTTP uptime monitors that just ping a URL, port monitoring verifies that specific network services are accepting connections:
- Connects to the exact port your application uses (e.g., MySQL on 3306, Redis on 6379).
- Performs a full TCP handshake to verify the port is actually accepting connections.
- Measures connection time so you can spot performance degradation before it becomes an outage.
- Tests from external locations to catch firewall misconfigurations, security group issues, and network problems.
- Sends intelligent alerts only when there's a real problem, not false alarms.
With MonitorPlatform, you get all of this in one dashboard—no agents to install, no complicated configuration, and alerts that reach you instantly via email, Slack, Discord, or webhooks.
Common Services You Should Be Monitoring
If your application depends on it, you should be monitoring it. Here are the most critical ports teams forget to monitor:
Databases (The Silent Killers)
- MySQL (3306/tcp) – The world's most popular database, and one outage can take down your entire app.
- PostgreSQL (5432/tcp) – Used by half the SaaS industry; a dead port means no transactions.
- MongoDB (27017/tcp) – NoSQL databases fail silently; monitor the port, not just the cluster.
- Redis (6379/tcp) – Your cache, sessions, queues—all gone if this port dies.
- Elasticsearch (9200/tcp) – Search down = features down = customer complaints.
Application Infrastructure
- RabbitMQ (5672/tcp) – Job queues stop processing if this port is blocked.
- Kafka (9092/tcp) – Event streams fail silently until you notice missing data.
- Memcached (11211/tcp) – Cache failures degrade performance before breaking entirely.
- Docker Registry (5000/tcp) – Can't deploy if you can't pull images.
Mail & Communication
- SMTP (25, 587, 465/tcp) – Transactional emails stop sending without obvious errors.
- IMAP (143, 993/tcp) – Email retrieval breaks for internal tools and integrations.
- LDAP (389, 636/tcp) – Authentication fails across all services if the directory is unreachable.
Remote Access & Management
- SSH (22/tcp) – Can't access your servers = can't fix problems.
- RDP (3389/tcp) – Windows server access for emergency troubleshooting.
- VPN Services (1194/udp, 500/udp) – Remote teams can't work if VPN ports are down.
Custom Services
- Your internal APIs on custom ports (8080, 3000, 4000)
- Microservices with non-standard ports
- Game servers, WebSocket servers, gRPC services
If it listens on a port and your app needs it, you should be monitoring it.
Setting Up Port Monitoring in MonitorPlatform (3-Minute Setup)
MonitorPlatform makes port monitoring dead simple. No agents, no CLI tools, no SSH access required.
Step 1: Add a Port Monitor
After logging in to MonitorPlatform:
-
Click "Add Monitor".
-
Select "Port Monitoring".
-
Choose from 25+ pre-configured presets, or enter custom port details:
Using a Preset (Recommended):
- Click "Quick Select" dropdown
- Choose "MySQL - 3306/tcp"
- Enter your host:
db.example.com - Click "Test Port Connection"
Custom Port:
- Host:
db-prod.example.com - Port:
3306 - Protocol:
TCP - Service Name:
Production MySQL - Timeout:
10 seconds
-
Click "Create Monitor".
That's it. MonitorPlatform immediately starts checking your port every 5 minutes (or faster on Pro plans).
Step 2: Verify It's Working
Within seconds of creating the monitor:
- Go to the monitor detail page.
- Click "Test Now" to run an immediate check.
- See the result:
- ✅ Port Status: OPEN
- ⚡ Connection Time: 45ms
- 🔍 Detected Service: MySQL
If the port is unreachable, you'll see:
- ❌ Port Status: CLOSED
- 🚨 Error: Connection refused
- 💡 Recommendation: Verify the service is running
Step 3: Configure Smart Alerts
Don't wait for customers to report problems. Set up alerts that reach you immediately:
-
Dashboard → Notifications
-
Add your preferred channels:
- Email – Persistent, auditable alerts
- Slack/Discord – Real-time team notifications
- Webhooks – Auto-create tickets in Jira, Linear, or PagerDuty
- SMS (Pro) – For business-critical services
-
Test each channel to make sure alerts actually work.
Now when your database port goes down at 3 AM, you'll know about it in seconds—not when your boss calls at 9 AM.
What a Professional Port Monitor Tracks
Basic port scanners only tell you if a port is open or closed. That's not enough for production systems.
MonitorPlatform tracks everything you need to know:
1. Port Status (OPEN / CLOSED / TIMEOUT / FILTERED)
- OPEN – Port is accepting connections. All good.
- CLOSED – Port is not accepting connections. Service might be down.
- TIMEOUT – Connection attempt timed out. Network issue or firewall blocking.
- FILTERED – Port might be blocked by firewall or security group.
Each status triggers different alert levels, so you get the right urgency.
2. Connection Time (Milliseconds)
Track how long it takes to connect to your service:
- < 50ms – Excellent, local or well-optimized
- 50–200ms – Normal for remote services
- 200–500ms – Slow, investigate network or service performance
- > 500ms – Critical, users are experiencing lag
Watch for trends: if connection times slowly increase, your service is degrading even if it's still "up."
3. Service Detection
MonitorPlatform automatically recognizes common services:
- MySQL, PostgreSQL, MongoDB, Redis
- HTTP, HTTPS, SSH, FTP
- SMTP, IMAP, LDAP
- RabbitMQ, Kafka, Elasticsearch
This helps you quickly identify what broke when scrolling through dozens of monitors.
4. Historical Data & Trends
Every check is logged so you can:
- See exactly when a port went down
- Calculate uptime percentage over 30/60/90 days
- Identify patterns (does this port fail every Tuesday at 2 AM?)
- Generate compliance reports for audits
5. Protocol Support (TCP & UDP)
- TCP – Most services (databases, web servers, APIs)
- UDP – DNS, DHCP, VPN, some game servers
MonitorPlatform supports both, so you can monitor anything.
TCP vs. UDP: Which Should You Use?
Most services use TCP, but here's when to use each:
Use TCP Monitoring When:
- Monitoring databases (MySQL, PostgreSQL, MongoDB, Redis)
- Web services (HTTP, HTTPS, APIs)
- Application servers (SSH, RDP, FTP)
- Email servers (SMTP, IMAP, POP3)
- Message queues (RabbitMQ, Kafka)
Why: TCP requires a full connection handshake, so if it succeeds, you know the service is definitely accepting connections.
Use UDP Monitoring When:
- DNS servers (port 53)
- DHCP servers (port 67/68)
- VPN services (OpenVPN, WireGuard)
- Game servers (Minecraft, some custom games)
- Syslog servers (port 514)
Why: UDP is connectionless, faster, but less reliable. If you're monitoring a UDP service, you need a UDP monitor.
Pro Tip: If you're not sure, use TCP. 95% of services use TCP.
Best Practices for Port Monitoring
Port monitoring is most effective when combined with solid operational practices:
Monitor All Critical Dependencies
Don't just monitor your main database. Monitor:
- Primary database servers
- Read replicas
- Cache layers (Redis, Memcached)
- Message queues (RabbitMQ, Kafka)
- Internal APIs and microservices
- Third-party services you depend on
If your app needs it to function, it should be monitored.
Set Realistic Check Intervals
- 5 minutes – Good for most production services (free plan default)
- 1 minute – Better for business-critical databases (Pro plan)
- 30 seconds – Mission-critical services where every second counts (Enterprise)
Balance alertness with cost. Checking every second is overkill for most use cases.
Use Maintenance Windows
Planning to restart your database? Enable a maintenance window so you don't get spammed with false alerts:
- Go to monitor details
- Click "Maintenance Windows"
- Schedule your maintenance
- Checks continue, but alerts are suppressed
This keeps your alert channels clean and trustworthy.
Monitor from External Locations
Internal monitoring (from inside your network) won't catch:
- Firewall misconfigurations blocking external access
- DNS resolution failures
- CDN or load balancer issues
- Routing problems between regions
MonitorPlatform checks from external locations, just like your users connect, so you catch the same issues they would.
Document Your Ports
Keep a living document of:
- Which ports each service uses
- Who owns each service
- What depends on each port
- Emergency contact for each service
When a port goes down at 3 AM, you need to know who to wake up and what depends on it.
Common Port Monitoring Issues (And How to Fix Them)
Issue 1: Monitor Says Port Is Closed, But Service Is Running
Possible Causes:
- Firewall or security group blocking external access
- Service bound to localhost (127.0.0.1) instead of 0.0.0.0
- Wrong host or port in monitor config
- VPN or network routing issue
How to Fix:
# 1. Check if service is actually listening
netstat -tulpn | grep :3306
# 2. Verify firewall rules
sudo ufw status
sudo iptables -L
# 3. Check service config (MySQL example)
grep bind-address /etc/mysql/my.cnf
# Should be 0.0.0.0 or specific IP, NOT 127.0.0.1
# 4. Test from monitoring server's perspective
telnet db.example.com 3306
Issue 2: Intermittent Failures
Port is up most of the time, but occasionally reports as down.
Possible Causes:
- Network instability
- Service occasionally overwhelmed and refusing connections
- Load balancer health checks interfering
- Connection pool exhaustion
How to Fix:
- Increase timeout value in monitor settings
- Check service logs during failure times
- Monitor service-level metrics (CPU, memory, connections)
- Consider adding more capacity or read replicas
Issue 3: Alerts But No Real Problem
Getting alerts but service is fine when you check.
Possible Causes:
- Timeout too aggressive (service is slow, not down)
- Temporary network blip
- Rate limiting or connection limits
- Service briefly restarting
How to Fix:
- Increase timeout from 5s to 10s or 15s
- Configure alert delays (only alert after 2–3 consecutive failures)
- Check if service has connection limits you're hitting
Issue 4: Connection Time Slowly Increasing
Port is open, but connection times are creeping up from 50ms to 300ms over weeks.
Possible Causes:
- Database growing and queries slowing down
- Network congestion
- Resource exhaustion (CPU, memory, disk I/O)
- Connection pool issues
How to Fix:
- Review service metrics (query times, resource usage)
- Add database indexes
- Scale up server resources
- Implement caching layer
- Optimize slow queries
Advanced: Bulk Port Scanning
Need to check multiple ports quickly? Use the Bulk Port Check API:
curl -X POST https://api.monitorplatform.com/api/v1/monitors/port/bulk-check \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"host": "db.example.com",
"ports": [3306, 5432, 6379, 27017],
"protocol": "tcp",
"timeout": 10
}'
Response:
{
"host": "db.example.com",
"results": [
{"port": 3306, "status": "OPEN", "connection_time": 45.2},
{"port": 5432, "status": "OPEN", "connection_time": 52.8},
{"port": 6379, "status": "CLOSED", "connection_time": null},
{"port": 27017, "status": "OPEN", "connection_time": 38.1}
]
}
This is perfect for:
- Auditing which ports are exposed on a server
- Validating firewall rules after changes
- Discovering what services are running
- Quick health checks during incidents
Port Monitoring for Different Team Sizes
Solo Developer / Small Startup
What to Monitor:
- Production database (1 monitor)
- Redis/cache layer (1 monitor)
- Any internal APIs (1–2 monitors)
Alert Channels:
- Email to yourself
- Slack/Discord to team channel
Check Interval: 5 minutes (free plan)
Cost: Free (up to 10 monitors)
Growing SaaS (10–50 People)
What to Monitor:
- All production databases (MySQL, PostgreSQL, Redis)
- Read replicas
- Message queues (RabbitMQ, Kafka)
- Internal APIs and microservices
- Staging environments
Alert Channels:
- Email to on-call rotation
- Slack/Discord to #engineering-alerts
- PagerDuty for critical services
Check Interval: 1–5 minutes
Cost: Pro plan ($29–99/mo for 100 monitors)
Enterprise / High-Availability Systems
What to Monitor:
- Every single port in production
- Multi-region redundancy
- Third-party dependencies
- Internal and external monitoring
Alert Channels:
- Multi-channel alerting (email, Slack, PagerDuty, SMS)
- Escalation policies
- Incident management integration
Check Interval: 30 seconds to 1 minute
Cost: Enterprise plan (custom pricing, unlimited monitors)
Security Considerations
Port monitoring inherently tests network access, which has security implications:
What MonitorPlatform Does
- Monitors only establish outbound connections (like a user would)
- No exploitation, no brute force, no payload injection
- Checks are lightweight and non-intrusive
- Fully compliant with responsible disclosure practices
What You Should Do
- Whitelist monitoring IPs if your firewall blocks external connections
- Don't expose sensitive internal ports publicly just to monitor them
- Use VPN or bastion hosts for internal-only services
- Monitor the monitor – ensure your monitoring system itself is secure
Monitoring Internal Services
If your database is on a private network (as it should be), you have options:
Option 1: Monitor via VPN
Set up MonitorPlatform checks through your VPN endpoint.
Option 2: Bastion Host
Expose a specific port through a hardened bastion server.
Option 3: Internal Monitoring Agent
Deploy MonitorPlatform agent inside your network (Enterprise feature).
Option 4: Monitor the Proxy/Load Balancer
If your app accesses the database through a proxy, monitor that instead.
Port Monitoring vs. Application Health Checks
| Feature | Port Monitoring | Application Health Check |
|---|---|---|
| What It Checks | Port is accepting connections | App logic is working correctly |
| Speed | < 100ms | Varies (could be seconds) |
| Depth | Network layer | Application layer |
| Best For | Infrastructure services | Web apps, APIs |
| Example | MySQL port 3306 is open | /health endpoint returns 200 OK |
The Right Approach: Use both.
- Port monitoring catches infrastructure failures (database down, firewall misconfigured)
- Health checks catch application failures (deadlocks, logic errors, crashes)
Together, they give you full visibility.
FAQ: Port Monitoring
Can I monitor ports on localhost or 127.0.0.1?
Yes, but only if your monitoring server has access to that host. For most users, you'll monitor public IPs or domain names. For internal services, see "Security Considerations" above.
What's the minimum check interval?
- Free plan: 5 minutes
- Pro plan: 1 minute
- Enterprise: 30 seconds (configurable)
Can I monitor IPv6 ports?
Yes. MonitorPlatform supports both IPv4 and IPv6 addresses.
What happens if the port is firewalled?
You'll get a TIMEOUT or FILTERED status. Check your firewall rules, security groups, or network ACLs.
Do you support custom protocols (not TCP/UDP)?
Not yet. TCP and UDP cover 99% of use cases. If you need ICMP ping, SCTP, or other protocols, contact us about Enterprise options.
Can I monitor ports behind a load balancer?
Yes! Monitor the load balancer's public IP and port. This is actually better because it tests the full stack, not just the backend server.
How many port monitors can I create?
- Free: 10 monitors total (all types)
- Pro: 100 monitors
- Enterprise: Unlimited
What if I need to monitor 100+ ports?
Upgrade to Pro or Enterprise. We'll work with you to optimize your monitoring strategy and reduce costs.
Can I get historical data for compliance audits?
Yes. All check results are stored indefinitely. You can export them for SOC 2, ISO 27001, or other audit requirements.
Does port monitoring use a lot of bandwidth?
No. Each check is a single TCP handshake (< 1KB data). Even checking every minute uses negligible bandwidth.
Turn Critical Services from "Fingers Crossed" to "Fully Monitored"
Database outages. Blocked ports. Silent failures. These are the infrastructure disasters that cause customer-facing downtime while your basic uptime monitors report "everything's fine."
Port monitoring closes that gap. It tells you exactly which services are reachable and how fast they're responding, so you catch problems before they cascade.
MonitorPlatform gives you:
- 25+ pre-configured port presets for instant setup
- TCP and UDP support for any network service
- Connection time tracking to spot performance degradation
- Smart alerts via email, Slack, Discord, and webhooks
- Historical data for compliance and trend analysis
Set up port monitoring for your critical services today. It takes three minutes and could save you from your next middle-of-the-night database disaster.
Your databases should never fail silently. With the right monitoring, they won't.
Please Note: The API aceess is not enabled for public. We will make this available soon for public access.
Ready to monitor your ports? Sign up for MonitorPlatform and start protecting your infrastructure in under 5 minutes.
