Check HTTP(S)

Qué verifica

Un monitor HTTP(S) pide la URL en su intervalo desde cada una de sus regiones. Comprueba el código de estado y, si lo defines, una palabra clave o una expresión regular en el cuerpo, y registra el tiempo de respuesta. Los subchecks opcionales de certificado, cabeceras de seguridad e higiene DNS se ejecutan en el mismo monitor, así que un host que falla abre un incidente, no cuatro.

Úsalo cuando

• Un servicio tiene un endpoint HTTP que responde cuando el servicio está sano: una ruta de health, una página de inicio o una ruta de API.
• La respuesta necesita una comprobación del contenido, no solo de que el endpoint responda: un código de estado, una cadena en el cuerpo o un patrón.
• El certificado, la postura de cabeceras y los registros SPF, DMARC y CAA del dominio deben comprobarse en el mismo monitor, no en 3 monitores más.

No ejecuta recorridos de navegador, no inicia sesión y sigue como máximo 5 redirecciones. Para un puerto sin HTTP, usa el check de puerto TCP. Para un certificado que merece su propio incidente, usa el check de certificado TLS.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Configuración

Objetivo. Una URL completa con esquema (https:// o http://). La sonda resuelve y valida la URL y cada salto de redirección antes de pedirlos. Rechaza las direcciones de loopback, privadas, link-local y de metadatos de nube, así que el monitor no puede apuntar a una red interna.

Certificado TLS

En una URL https, el mismo monitor evalúa el certificado que le entrega el servidor: el handshake, la cadena, el emisor y el sujeto. El formulario activa este subcheck para cada URL https.

Cabeceras de seguridad

La sonda envía una segunda petición y busca en su respuesta las cabeceras seleccionadas. Solo cuenta su presencia. Una cabecera ausente es un hallazgo de postura, no una caída, así que la gravedad por defecto es degraded.

Higiene DNS

La sonda lee SPF, DMARC y CAA del dominio como configuración. Estos registros deciden si el correo del dominio se entrega y quién puede emitir certificados para él. El hallazgo aparece con el resultado y nunca cambia el estado del monitor.

Cómo se ejecuta un check

1. Cuando toca un check, cada región compila primero la regex. Una regex inválida termina el check como error. Cada check expira a los 10 s.
2. El nodo resuelve el host con su propio resolver y valida cada dirección de la familia seleccionada contra los rangos bloqueados. Después, cada dirección recibe su propia petición, con la conexión fijada a esa dirección.
3. La propia sonda sigue las redirecciones, como máximo 5 saltos. Resuelve y valida de nuevo cada salto antes de pedirlo.
4. La sonda evalúa primero el código de estado y después la palabra clave y la regex. Solo lee el cuerpo cuando una de las dos está definida, y todas las aserciones se combinan con AND.
5. Solo un check https superado con el subcheck de certificado TLS activado ejecuta la política de certificado, una vez por check. Un check superado o degradado añade la calificación de cabeceras y el hallazgo de higiene DNS como subresultados separados.
6. La región envía su resultado al control plane. La política de alertas decide si un resultado fallido abre un incidente cuando el quórum lo confirma. Un resultado degradado queda fuera de la evaluación de incidentes.

Desliza lateralmente para ver la vista del producto.

app.perstat.io

Qué contiene un resultado

Código de estado

El estado final tras las redirecciones, evaluado frente a expected_status.

Tiempo de respuesta

Tiempo hasta la respuesta, cuerpo incluido cuando se lee, por región y por dirección (latency_ms).

Línea de detalle

Una línea que dice qué ha pasado, por ejemplo HTTP 200, keyword not found o regex did not match. También nombra un estado inesperado o el error de transporte.

Capa de causa

Si el fallo está en el DNS del objetivo (nombre no encontrado) o, tras una resolución correcta, en el propio objetivo. Cualquier otra causa se registra como unknown.

Certificado

Nombre común y nombres alternativos, emisor, fechas de validez con los días restantes y estado de confianza.

Cabeceras de seguridad

Cuáles de las cabeceras pedidas estaban presentes y cuáles faltaban.

Higiene DNS

Los hallazgos de SPF, DMARC y CAA, por ejemplo una política DMARC en none o un registro CAA ausente.

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

• okEl código de estado coincide y todas las aserciones se cumplen. Un certificado dentro de su ventana de aviso mantiene este estado.
• degradadoFalta una cabecera de seguridad con la gravedad por defecto, o falla una familia IP mientras la otra responde.
• caídoLa petición falla, expira o se bloquea, o no coinciden el código de estado o una aserción. También cuentan una política de certificado fallida (caducado, handshake rechazado, emisor o sujeto no coincidente) y una cabecera ausente con gravedad failed.
• errorLa configuración no se puede ejecutar, por ejemplo por una regex inválida. 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.

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. Un paquete de 50 monitores más cuesta 39 €.

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": "Order API",
  "type": "http",
  "interval_seconds": 60,
  "config": {
    "url": "https://orders.example.com/health",
    "expected_status": 200,
    "keyword": "ok",
    "tls_cert": { "enabled": true, "warn_days": 21 },
    "security_headers": {
      "enabled": true,
      "headers": ["strict-transport-security", "content-security-policy"],
      "missing_severity": "degraded"
    },
    "dns_hygiene": { "enabled": true }
  }
}

Cada interfaz, con su límite

Límites

• La sonda no ejecuta recorridos de navegador ni JavaScript, y no sigue flujos de inicio de sesión. No envía cuerpo de petición ni cookies.
• El método y las cabeceras de petición se fijan por API o MCP, no en el formulario.
• La sonda sigue como máximo 5 saltos de redirección, y una cadena más larga hace fallar el check.
• La calificación de cabeceras de seguridad comprueba la presencia, no los valores.
• La sonda rechaza los objetivos en direcciones privadas, de loopback, link-local y de metadatos de nube.
• No todas las regiones sondean IPv6, así que seleccionar ipv6 restringe las regiones utilizables.

Tipos de check relacionados

• Check de cabeceras de seguridadPresencia de 5 cabeceras de seguridad en una URL, como monitor propio con registro propio.
• Check de certificado TLSCaducidad, emisor y sujeto de un certificado por handshake TLS directo, con un aviso antes de la caducidad.
• Check de puerto TCPSi un puerto acepta conexiones, opcionalmente con el certificado que sirve.
• Check de higiene DNSSPF, DMARC con su política y CAA de un dominio, calificados como postura y nunca como caída.

Todos los tipos de check