TCP port check Beta
POST /api/v1/monitors
Type tcp: connect to a port on a host. Connecting is the measurement, and you can go further by sending a string and checking what comes back.
There is no separate endpoint for this: it is the ordinary create a monitor call with type set to "tcp". The same settings apply when you update a monitor with PATCH /api/v1/monitors/{id}.
Every type shares the same interval, retries, alerting, maintenance, results and reports. Only the settings below differ. See Check types for how the nine types compare.
Up or down
- With no
sendStringorexpectString, the check is up as soon as the port accepts the connection. The response time is how long connecting took. - With
expectString, the reply must contain that text. If the connection closes first, the check is down: The connection closed before the expected reply. - A refused connection, an unreachable host or a timeout is down, with a plain reason such as Connection refused.
- The response time is always the connect time, even when a reply is read afterwards.
Settings that apply
| Setting | Notes |
|---|---|
url required | The host, for example db.example.com. Not a URL. |
port required | 1 to 65535. There is no standard port to fall back on, so this type needs one. |
sendString | Written once the socket opens. Up to 500 characters. \r, \n and \t are sent as real characters. |
expectString | The reply must contain this. Up to 500 characters. |
timeoutSeconds | How long to wait for the connection and the reply. |
Create one
A plain port check: is anything listening?
A check that speaks first. This asks a Redis server to reply +PONG:
You can also write the port into the host: "url": "db.example.com:5432" is stored as host db.example.com with port: 5432.
Related
- UDP port check: the same idea without a connection
- Mail server checks: a port check that understands the protocol
- Check types: hosts, ports and duplicates