Watch the ports your app depends on.
MySQL, Redis, SMTP, the job queue: if it listens on a port, UptimeStatus can tell you the moment it stops.
Your website was never the first thing to break.
When Redis dies, your homepage keeps returning 200 for a while: caches miss, jobs pile up, and the error tracker slowly fills with timeouts. By the time an HTTP check notices, you are twenty minutes into an incident that started at a port.
A TCP port monitor watches the dependency itself. The probe connects to the exact host and port your app uses, so you hear that the database stopped accepting connections before the symptoms surface anywhere else.
A connect is a measurement, not a coin flip.
Each check records whether the port accepted the connection and how many milliseconds the handshake took, from which probe region. A port that will not answer within ten seconds is treated as closed, recorded as such, and the transition opens an incident naming the host and port.
That history matters between outages too. A queue server whose connect time crept from 8ms to 900ms over a week is telling you something, and the chart is sitting there when you want it.
What TCP port monitoring includes.
- Any TCP service MySQL, Postgres, Redis, SMTP, RabbitMQ: if it accepts TCP connections, it can be monitored. No HTTP endpoint required.
- Configurable port set the port on the monitor and the probe connects to exactly that. Defaults to 443 if you leave it out.
- Connect timing every check records how long the TCP handshake took in milliseconds, so a service getting slower is visible in the history.
- Automatic incidents when a port stops accepting connections, an incident opens naming the host and port, and your channels are notified.
- 90-day history every result is stored with its timing and probe region, so you can trace exactly when a service went quiet.
- 10 notification channels email, SMS, Slack, Discord, Microsoft Teams, PagerDuty, Opsgenie, Pushover, ntfy, and webhooks.
One API call per port.
A port monitor is a record with a host, a type, and a port in its config. Create one from the dashboard, or script the whole set from your infrastructure repo so every database and queue you provision comes with its watcher.
The same API powers the dashboard, so anything you can click, you can automate.
curl -X POST https://uptime-status.org/api/monitors \ -H 'Content-Type: application/json' \ -d '{ "name": "Primary MySQL", "url": "db-1.yourcompany.com", "type": "tcp_port", "config": "{\"port\": 3306}" }'
TCP port monitoring, answered.
What exactly does a TCP port check do?
It opens a TCP connection to your host on the port you configured and measures how long that takes. If the connection is accepted, the service is up and the timing is recorded. If it is refused or nothing answers within ten seconds, the port is marked closed or unreachable and an incident opens.
Which services is this for?
Anything that speaks TCP but not HTTP: databases like MySQL and Postgres, Redis, SMTP and IMAP servers, message queues, game servers, custom daemons. If your app depends on it through a port, you can watch that port directly.
Does a successful connect mean the service is healthy?
It means the service is accepting connections, which catches the most common failure: the process died, the box rebooted without it, or a firewall change cut it off. It does not run protocol-level queries, so a database that accepts connections but answers slowly needs the connect timing history, where that slowdown shows up.
Can I monitor ports that are not exposed to the internet?
The hosted probes connect from the public internet, so the port must be reachable from outside. For databases and queues that rightly are not, self-host the open-source version inside your network and run the checks from there. If a database port is publicly reachable and should not be, port scan monitoring is built to catch exactly that.
How often do port checks run?
As often as every 30 seconds on the Pro plan and every 5 minutes on Free. Self-hosted installs set their own interval.
Pairs well with.
Ping monitoring
Port closed and host unreachable are different incidents. A ping check on the same host tells them apart.
Learn morePort scan monitoring
A port check watches one port you know about. A port scan finds the ones you did not know were open.
Learn moreNotifications
Route database alerts to the on-call channel and staging noise somewhere quieter, across 10 channels.
Learn moreStart monitoring in under 2 minutes.
No credit card required for the self-hosted, open-source version.