Check de puerto TCP

Qué verifica

Un monitor de puerto TCP se conecta a host y puerto en su intervalo desde cada una de sus regiones, una vez por dirección resuelta. Solo evalúa si la conexión se aceptó, se rechazó o expiró, y registra cuánto tardó el connect. No envía carga útil ni lee ningún banner.

Úsalo cuando

• Un servicio escucha en un puerto pero no tiene endpoint HTTP, por ejemplo una base de datos, una cola de mensajes o un puerto SSH, LDAP o Redis.
• La pregunta es si se llega al puerto, no qué protocolo hay detrás.
• Un puerto TLS sin HTTP debe tener su certificado vigilado sin un segundo monitor.

No habla el protocolo que hay detrás del puerto: ni banner, ni inicio de sesión, ni consulta. Para un servidor de correo, usa el check SMTP o IMAP, y para un endpoint HTTP, usa el check HTTP(S). Para un puerto que pasa a TLS solo tras un diálogo en claro (STARTTLS), usa el check SMTP o IMAP para vigilar su certificado.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Configuración

Objetivo. Un nombre de host o una dirección IP sin esquema, ruta ni espacios (etiquetas de hasta 63 caracteres, 253 en total), más un puerto de 1 a 65535. La sonda resuelve el host con su propio resolver en el momento del check.

Certificado TLS

Con el interruptor activado, a un connect superado le sigue un handshake TLS directo por check, no por dirección, en el puerto del monitor, salvo que tls_cert.port indique otro. La sonda evalúa el certificado con tus reglas de caducidad, emisor y sujeto. Sin el interruptor, el check no lee ningún certificado y la vista del monitor no muestra ninguno.

Cómo se ejecuta un check

1. La sonda lee la configuración. Un puerto ausente termina el check como error antes de cualquier acceso a la red.
2. Cuando toca un check, cada región resuelve el host con el resolver propio del nodo. Valida cada dirección de la familia seleccionada contra los rangos bloqueados.
3. Cada dirección recibe un connect TCP con un timeout de 10 s. El tiempo hasta la conexión aceptada es el tiempo de respuesta de esa dirección.
4. Solo un check superado con el subcheck de certificado TLS activado ejecuta la política de certificado. Se ejecuta una vez por check, como handshake TLS directo en el puerto del monitor o en tls_cert.port.
5. La región envía su resultado al control plane. Cuando el quórum de regiones y checks consecutivos de la política de alertas lo confirma, se abre un incidente.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Qué contiene un resultado

Tiempo de conexión

Tiempo desde la llamada connect hasta la conexión aceptada, por región y por dirección (latency_ms).

Línea de detalle

Una línea que dice qué ha pasado: el puerto está abierto, la conexión se ha rechazado con el motivo o el connect ha expirado.

Certificado

Con el subcheck activado: nombre común y nombres alternativos, emisor, fechas de validez, y estado de autofirma y de confianza. Al alcanzar la ventana de aviso, el resultado lleva también el aviso de caducidad.

Región, familia, dirección

Cada resultado lleva la región que lo midió, y un subresultado por familia IP y por dirección.

Estados y gravedad

• okLa conexión se aceptó en todas las direcciones comprobadas. Un certificado dentro de su ventana de aviso mantiene este estado.
• degradadoUna familia IP, o una de varias direcciones resueltas, falla mientras las demás responden, con el family_fail_severity por defecto. Un connect aislado no tiene resultado degradado.
• caídoLa conexión se rechaza o expira, o el host no resuelve o resuelve a una dirección bloqueada. Con el subcheck activado, también cuenta una política de certificado fallida: caducado, handshake rechazado o emisor o sujeto no coincidente. Con family_fail_severity: failed, una familia que falla también cuenta aquí.
• errorLa configuración no se puede ejecutar porque falta el puerto. Cuenta como caída con gravedad critical.

Confirmado por quórum: por defecto, 2 regiones deben informar del fallo antes de que se abra un incidente. El valor por defecto de la organización pide 2 regiones y 2 checks consecutivos. Un monitor puede llevar su propia regla con número o porcentaje, checks consecutivos y una duración mínima.

Planes y límites

Intervalo mínimo

300 s en Free, 60 s en Pulse, 30 s en Sentinel, 15 s en Command y 10 s en Enterprise. El formulario web ofrece 30 s, 1 min, 5 min, 15 min y 1 h. Los mínimos de 15 s y 10 s solo se alcanzan por MCP.

Regiones

2 de 6 en Free, 3 de 6 en Pulse y las 6 desde Sentinel. Si pides más regiones de las que permite el plan, se rechazan, no se recortan.

Monitores

10 en Free, 50 en Pulse, 150 en Sentinel, 500 en Command y un cupo a medida en Enterprise. Once tipos de check de sonda comparten este cupo, mientras que los agentes de host y los heartbeats tienen la suya.

Comparar todos los límites

Desde la pipeline o un agente

La misma config sirve en el paso de despliegue, en un cliente MCP como Claude Code y en el formulario de arriba. create_monitor necesita una clave de API válida para toda la organización. Si omites regions, el plan aplica su valor por defecto.

{
  "name": "Postgres primary",
  "type": "tcp",
  "interval_seconds": 60,
  "config": {
    "host": "db.example.com",
    "port": 5432
  }
}

Cada interfaz, con su límite

Límites

• El check no lee ningún banner, no ejecuta ningún diálogo de protocolo y no envía carga útil. Termina cuando se acepta la conexión.
• El puerto 0 se rechaza. Un monitor guardado sin puerto termina cada check como error.
• El subcheck TLS es un handshake directo en el puerto del monitor, salvo que tls_cert.port indique otro. Para un puerto que pasa a TLS tras un diálogo en claro (STARTTLS), usa el check SMTP o IMAP.
• La sonda no se conecta a objetivos que resuelven a direcciones de loopback, privadas, link-local, de metadatos de nube o similares. El check falla con el detalle internal or private, blocked. Nada impide guardar un monitor así.
• No todas las regiones sondean IPv6, así que seleccionar ipv6 restringe las regiones utilizables.

Tipos de check relacionados

• Check HTTP(S)Disponibilidad y respuesta de una URL, con aserciones sobre estado, cuerpo y TLS.
• Check de certificado TLSCaducidad, emisor y sujeto de un certificado por handshake TLS directo, con un aviso antes de la caducidad.
• Check SMTPBanner y EHLO de un servidor de correo, con una comprobación opcional del certificado por STARTTLS o TLS implícito.
• Check pingAlcanzabilidad de un host por ICMP echo: respuestas, pérdida e ida y vuelta media desde cada región.

Todos los tipos de check