Tipos de check

El plan fija intervalos y regiones

Según el plan, los intervalos bajan hasta 10 segundos. El formulario web ofrece 30 segundos o más. Los intervalos más cortos se fijan mediante MCP. La página de precios indica el intervalo mínimo de cada plan.

Los 11 tipos de check regionales usan las regiones incluidas en el plan: 2 en Free, 3 en Pulse y las 6 desde Sentinel. Su política regional es configurable y usa por defecto un quórum de 2 regiones. La página de monitorización de uptime explica la regla regional.

agent y heartbeat no llevan región ni necesitan quórum, porque el informe llega de tu host o de tu job.

Comprueba URL y cabeceras de seguridad

http pide una URL y comprueba el resultado con aserciones: un código de estado esperado, una palabra clave que el cuerpo debe contener o una expresión regular sobre el cuerpo. Sigue redirecciones hasta 5 saltos y valida cada salto contra objetivos SSRF antes de pedirlo. Un monitor http puede llevar además subchecks opcionales de certificado TLS, cabeceras de seguridad e higiene DNS, así que un solo monitor cubre lo que antes requería cuatro. Solo el subcheck de certificado necesita https.

http_headers comprueba las cabeceras de seguridad como monitor aparte, con su propio registro.

Comprueba DNS, dominios y certificados

dns resuelve un nombre y compara el conjunto de respuestas con lo que esperas. Un monitor DNS puede además cotejar sus respuestas con el conjunto de respuestas de otro monitor. Una divergencia sigue el flujo normal de incidentes.

dns_hygiene comprueba SPF, DMARC y CAA como configuración. Estos registros deciden si tu correo llega y quién puede emitir certificados para ti.

domain vigila la capa de registro: la coherencia de NS y SOA, DNSSEC y la caducidad en WHOIS. Un dominio dentro de su ventana de aviso, de 14 días por defecto, pasa a degradado.

ssl_cert vigila un certificado directamente, con independencia de cualquier monitor http. Comprueba la validez, la cadena, la caducidad y el emisor, y detecta certificados autofirmados.

Comprueba los servidores de correo

smtp e imap comprueban la ruta de correo de la que dependen los restablecimientos de contraseña y las facturas. Desde las regiones de sonda de tu plan, verifican que el servidor acepta conexiones y habla su protocolo.

Comprueba la alcanzabilidad y la ruta de red

ping comprueba si se puede llegar al host. tcp comprueba si un puerto acepta una conexión, opcionalmente con el certificado TLS que se sirve en ese puerto. traceroute registra la ruta, que es la prueba que necesitas cuando el fallo está en una red intermedia y no en tu servicio.

Vigila un host con el agente

agent vincula un monitor al agente de host. Comprueba la disponibilidad con un periodo de gracia, la CPU, la memoria y el disco frente a umbrales, y los servicios por nombre con una gracia contra el flapping. Una métrica sin datos recientes no produce ningún resultado en lugar de una falsa alarma, y un monitor de disponibilidad marca down a un agente que calla.

Una sola línea instala el agente desde el punto de distribución en Linux (x86_64, aarch64) y en macOS como binario universal. En Linux funciona como una unidad de systemd reforzada. Nunca recopila líneas de comandos, variables de entorno ni nombres de usuario.

El agente se actualiza solo con releases firmadas con ed25519. Verifica cada release antes del reemplazo, aplica fail-closed y no necesita un helper con root. Se desinstala limpiamente y se da de baja en el cockpit.

Vigila jobs con un heartbeat

heartbeat invierte la dirección: tu job llama a Perstat en lugar de que Perstat llame a tu servicio. Eso cubre una ejecución de cron, una copia de seguridad nocturna, un importador o cualquier otra cosa sin una dirección que sondear.

Recibes una URL secreta, y el job la pide al terminar. Si esa llamada no llega dentro del periodo más la gracia que hayas fijado, el monitor pasa a down. Un job que nunca se ejecutó es el fallo que la monitorización ordinaria no puede ver, porque no se rompió nada que alguien pudiera alcanzar.

Cada heartbeat tiene un endpoint de éxito y un endpoint de fallo. Un job que se ejecutó y falló puede llamar al endpoint de fallo, que pone el monitor en down en la siguiente evaluación sin esperar a que venza el periodo. Tu script decide a qué endpoint llama, así que puede comunicar cualquier condición que sepa comprobar, no solo si el job se ejecutó.

La documentación de monitores contiene las URL exactas.

Los resultados regionales incluyen diagnóstico

• IPv4, IPv6 o ambas, por IP. Cada check de alcanzabilidad se ejecuta en las familias de direcciones que selecciones, y en IPv4 si no seleccionas ninguna. Los resultados quedan separados por familia e IP. Tú decides si un fallo en una familia cuenta como degradado o como fallido.
• El tiempo de DNS, aparte. Cuando corresponde, dns_ms se informa por separado de la latencia total, así que un resolver lento no parece una aplicación lenta.
• Atribución de la causa. Cuando un check de sonda compatible emite una atribución, nombra la capa: tu aplicación o tu DNS, la red, o nuestro resolver o nuestro propio nodo. Unknown sigue siendo válido mientras la causa no esté determinada, y no todos los resultados llevan una capa de causa.

Empieza a monitorizar gratis o haz el tour del producto. El tour no requiere registro.