Skip to content
Oh Dear

HTTP green, port closed

TCP port monitoring.

You manage client infrastructure you did not build. HTTP is green. The port is closed. An outside-in TCP connect to a host and port you name. A successful connect means the port accepted the connection, not that the application behind it did anything useful.

10-day free trial · No credit card required · Every feature included

Checked every minute TCP connect from outside
  • Bitmovin
  • HBO Nordic
  • Obsidian
  • Laravel
  • Fathom Analytics
  • PHP 8
  • Stanford University
  • Takeaway.com
  • IGN
  • VRT NWS
  • spatie

Homepage still returns 200

The site is up. The port is closed.

The homepage answers. The status page you already watch looks fine. Then the client asks why the newsletter never went out, why the app cannot reach MySQL, or why nobody can SSH in to fix it.

You did not set up that server. You still own the relationship. For an agency with a portfolio of unrelated client domains, that is the whole job: know the port closed before the client notices the mail that never went out.

HTTP uptime cannot see this. A site stays up while port 25 refuses a connect, and a host answers every ping while the database port is shut. Those are three different questions about the same machine.

You give it a hostname and a port. SMTP on 25, MySQL on 3306, Redis on 6379, SSH on 22 are examples of what people watch, not a catalogue Oh Dear discovers for you. If the port stops accepting connections, the person who can fix it hears about it.

Casey Sprague
Oh Dear detected an issue that our other uptime monitor did not!

Casey Sprague, CTO at thera-LINK

A homepage answering 200 says nothing about whether port 25 is still open.

One TCP connect

What this check sees, and what it does not.

This check answers exactly one question: did this port accept a TCP connection from Oh Dear? Everything past that belongs to a different check.

What it checks

  • A TCP connect from Oh Dear's servers to the hostname and port you name.
  • Whether that port is open and accepting connections.
  • Optionally, whether the welcome banner contains text you specified.
  • Optionally, whether the reply to a string you send contains text you expect.

What it does not

A TCP connect can succeed while the application behind the port is not processing any work. This is not a synthetic checkout, and a banner match is evidence that something is speaking the right protocol, not that a message was delivered.

Operational ownership

Send the closed port to the person who owns the fix.

A closed mail port on client A is not the same incident as closed SSH on client B. Each monitor routes to the people responsible for that box, on the channels they already use.

The notification tells you about the problem; it is not a control panel. Slack cannot rerun the check; the next one runs on its own schedule regardless.

Slack
Email
Webhook
Explore notifications and routing

No feature tiers

Every check.
Every plan.

TCP port monitoring is included on every plan. You pay for the number of things you monitor, not per check.

Start with everything on.

TCP port monitoring sits with uptime, ping, certificates, DNS and the rest of the website-health toolkit.


  • TCP port monitoring included
  • Every feature on every plan
  • Plans scale by monitored site count
  • No credit card required
Start a free trial

10-day free trial. No credit card.

For the technically curious

How the TCP port check actually works.

You give Oh Dear a hostname and a port. Oh Dear opens a TCP connection to it from its own servers, and reports whether the connection was accepted.

  • The target. One hostname and one port per monitor. Two ports on the same box are two monitors, which is also what lets you route them to two different people.
  • No agent. The connection comes from Oh Dear's servers, from outside your network. Nothing is installed on the machine being checked.
  • Two locations. Each monitor has a primary location, and a failure there is re-checked from a second one in a different city and on a different provider. Both have to report the port down before a downtime notification goes out. If the first fails and the second succeeds, the run is a warning rather than downtime, and it does not affect your uptime figure.
  • Cadence. Every minute by default, and settable per monitor anywhere from one to sixty minutes.
  • Timeout. A connect that has not completed inside the timeout counts as a failure. New monitors wait one second. This is the wait for the connection, not how often the check runs.
  • Optional strings. Two separate assertions: match text in the welcome banner a service sends on connect, and send a string of your own then match text in the reply. Both are plain substring matches rather than patterns, and both are skipped when left empty. Useful for confirming something is still speaking SMTP rather than merely holding the port open.
  • Before you are alerted. Two minutes of downtime by default, settable from one to twenty. It is a duration rather than a count of failed checks, so raising it buys a quiet window over a blip without changing the check interval.
  • Published addresses. The addresses Oh Dear checks from are published at /used-ips, in JSON and CSV as well as HTML, and updated automatically as servers are added or retired. Fetch it on a schedule rather than pasting addresses into a firewall rule.

Want all the technical details?

Before the first check

Questions about TCP port monitoring.

What a TCP connect proves, how this differs from the neighbouring checks, and where it ends.

What is TCP port monitoring?

It is a TCP connect check to a specific host and port, run from Oh Dear's own servers with nothing installed on the box. A successful connect means the port accepted the connection. It does not prove the application behind it processed anything.

How is this different from website uptime monitoring?

Website uptime monitoring makes an HTTP(S) request to a public URL. This check opens a TCP connection to a port you name. A homepage can return 200 all day while SMTP, MySQL or SSH on the same box refuses every connection.

How is this different from ping monitoring?

Ping monitoring asks whether the host answers ICMP at all. This check asks whether one specific port is accepting connections. A machine can ping perfectly while port 25 is closed.

How is this different from port scanning?

This check watches the ports you name, every minute. Port scanning runs daily instead, and compares the ports it finds open against a list of the ones you expect. Use this check for "is my mail port still up", and port scanning for "what is open that should not be".

Can I monitor several ports on one host?

Yes, as separate monitors. Each one watches a single host and port, so two ports on the same machine are two monitors and can be routed to two different people.

Can Oh Dear check what the port actually replies?

To a point. You can have the check look for text in the welcome banner the service sends, and you can send a string of your own and match against the reply. That confirms something is speaking the protocol you expect, but it is not proof that mail was queued or a query ran.

Does this test a checkout or a login?

No. This check is not a synthetic checkout. It opens a connection and, optionally, matches a string. Anything that needs a real request with assertions belongs with API monitoring.

Do I need to allow Oh Dear through a firewall?

Often, yes, for ports that are not open to the world. Oh Dear publishes the addresses it checks from and keeps that list current as servers are added or retired, so you can fetch it on a schedule rather than copying addresses into a firewall rule by hand.

Is TCP port monitoring included in every plan?

Yes. Every feature is on every plan. You pay for the number of things you monitor, not per check.

See all other FAQ items

Get started

Start monitoring the ports you're already responsible for.

Add a host and port in under a minute. Every feature on. No credit card.