Your database runs on port 3306. Your cache on 6379. Your SSH on 22. If any of them stop accepting connections, your application breaks. Port Sentinel monitors every TCP port across your infrastructure and alerts you the moment a service goes dark. Pair with ping monitoring for full network coverage.
Service catalog
Click a category to see the ports, services, and why each one matters to your infrastructure.
MySQL / MariaDB
The most common relational database. Powers WordPress, Magento, and countless web applications.
PostgreSQL
Advanced open-source database favoured by enterprise teams and used by Heroku, Supabase, and Railway.
MongoDB
Document-oriented NoSQL database. Default port for MongoDB Community and Atlas self-managed.
Redis
In-memory data store used for caching, session management, and message queuing.
Elasticsearch
Search and analytics engine. Powers full-text search, log analysis, and real-time data pipelines.
Cascading failure
Your Redis cache stops accepting connections on port 6379. The application can't read sessions, so it falls back to the database for every request. The database connection pool overflows. MySQL on port 3306 stops accepting new connections. Every HTTP request returns a 500 error. Your uptime monitor finally detects the problem, six minutes after it started.
With port monitoring, you would have known about the Redis failure in 30 seconds. The on-call engineer restarts the service before the cascade reaches the database. Total user impact: under a minute.
This is why monitoring at the service layer matters. Ping checks confirm the server is on the network. HTTP checks confirm the web server responds. Port monitoring confirms that every individual service your application depends on is actually running.
Redis port 6379 stops accepting connections
Application sessions begin failing, users see errors
App falls back to database for every request
MySQL connections spike from 40 to 500
Database connection pool exhausted on port 3306
All application endpoints return 500 errors
HTTP monitor detects failure on port 443
With port monitoring: detected at +00:00. Without: detected at +06:00.
Understanding the difference helps you diagnose issues faster. Pulse Stack™ distinguishes all three in every check.
The TCP handshake completes successfully. The service behind this port is running and accepting connections. This is the expected state for all your monitored services.
Diagnosis
Healthy. Service is running normally.
Example
MySQL accepting queries on 3306
The server actively refuses the connection with a TCP RST packet. The server is reachable, but no service is listening on this port. The application has crashed or was stopped.
Diagnosis
Service down. Restart required.
Example
Redis stopped, port 6379 refused
No response received. The connection attempt times out. This usually means a firewall, security group, or network ACL is blocking traffic to this port. The service may or may not be running.
Diagnosis
Firewall or network issue. Check rules.
Example
SMTP blocked by cloud provider
Enter a host and port number. We start checking from 10+ locations immediately.
Security visibility
Every open port is a potential entry point. A forgotten development server on port 8080, an unpatched MongoDB instance on 27017, or an exposed Redis cache on 6379 without authentication are common vectors for data breaches.
Port monitoring serves a dual purpose: it verifies that services you need are running, and it alerts you if ports open that should not be. If a new service starts listening on an unexpected port after a deploy, you want to know about it immediately. Combine with SSL monitoring for complete security visibility.
Audit your port exposure regularly. Monitor every port you intentionally expose and investigate any unexpected changes. Pulse Stack™ tracks port state history so you can see exactly when a port opened, closed, or started being filtered.
Full-stack monitoring
A complete monitoring strategy works at every layer of the stack. Ping monitors the network. Port monitoring covers the service layer. HTTP checks test the application. Content monitoring verifies the output.
When a failure occurs, having monitors at multiple layers tells you exactly where the problem is. Server responding to ping but port 3306 closed? The database service crashed. Port open but HTTP returning 500s? The application has a bug. This layered approach eliminates guesswork and accelerates incident resolution.
All monitor types feed into the same dashboard, status pages, and alerting system. One platform for your entire infrastructure, from DNS resolution to domain expiry tracking.
50 monitors free forever. Upgrade when you need faster checks or more capacity.
Most popular
£29/month
All plans include multi-location checks, incident management, and public status pages. Full plan comparison →
Port monitoring covers the service layer. Add these for complete infrastructure visibility.
Everything you need to know about TCP port monitoring.
Monitor every TCP port on every server. Free for 50 monitors, no credit card required.
Start port monitoring free