Cómo monitorizar un sitio web con una comprobación HTTP

Configuración principal

• Monitoring enabled: interruptor maestro de encendido/apagado. Una tarea pausada conserva su configuración pero deja de comprobar y avisar.
• Interval schedule / Cron schedule: el simple deslizador de intervalo de abajo, o un constructor de cron (cada N minutos/horas, diario, semanal, mensual, o una expresión personalizada de 5 campos) para calendarios que un intervalo no puede expresar. Cron necesita un plan de pago.
• Interval: con qué frecuencia se ejecuta la comprobación, de 1 minuto a 24 horas; arrastra el deslizador o elige un valor del desplegable. El intervalo más corto disponible depende de tu plan.
• Timeout: cuánto esperar una respuesta antes de fallar, de 1 a 100 segundos (40s es un valor por defecto habitual). El tiempo de resolución DNS no cuenta.
• Tags: etiquetas separadas por comas para agrupar y filtrar monitores en el panel.
• Full Log: guarda cada resultado de la comprobación en lugar de agrupar los idénticos consecutivos.
• Open Stats: publica las estadísticas y el registro de comprobaciones de esta tarea en un enlace público.
• Attached monitors: cuatro comprobaciones extra ancladas a esta tarea en lugar de tareas aparte: DNSBL (lista negra de dominio), Domain Expiration/Certificate Expiration (recordatorios a 30/7/1 días), Web Risk (listas de malware/phishing de Google). Todas se ejecutan cada 12 horas; los recordatorios siguen las suscripciones Up de abajo, un mal resultado sigue Down/Repeat. Cada una tiene su propia guía; ver Relacionado.

Configuración de la petición

• HTTP Method: GET, HEAD, POST, PUT, DELETE, PATCH u OPTIONS. GET (por defecto) descarga la página y es necesario para las comprobaciones de palabra clave de contenido; HEAD solo obtiene cabeceras, la comprobación de disponibilidad más rápida; POST/PUT/PATCH también envían un cuerpo.
• Request body (solo POST/PUT/PATCH): Plain text envía exactamente lo que escribes (añade tu propia cabecera Content-Type); el modo Key-value lo construye a partir de filas de nombre/valor como form-urlencoded o JSON y fija Content-Type automáticamente.
• Redirect behavior: Immediate response juzga la primera respuesta tal cual; Follow redirects (por defecto) sigue la cadena, con un deslizador de Max redirects to follow (1-20); Redirect is error hace fallar ante cualquier redirección (no disponible en modo de aserciones).
• HTTP Headers: pares nombre/valor personalizados. Si se deja vacío, la sonda envía las cabeceras por defecto (User-Agent, Accept, Accept-Language, un Referer). Añade aquí una cabecera Authorization para autenticación por token o clave de API.
• Request authentication: revela usuario/contraseña para la propia autenticación por desafío HTTP del servidor (Basic, Digest, NTLM, Kerberos, Negotiate). Usa en su lugar una cabecera Authorization para autenticación por token anticipada.
• DNS Server Selection: Default DNS servers at locations; Public DNS servers of location's country; o Manually defined DNS servers (tus propias IP de resolutor). Las dos últimas necesitan un plan de pago.
• Disable DNS cache: fuerza una consulta DNS nueva en cada comprobación en lugar de reutilizar la caché del agente; útil justo después de un cambio de DNS.

Validación de respuesta

Por defecto una comprobación tiene éxito cuando el DNS resuelve, se completan la conexión TCP y el saludo TLS (para https), y el servidor devuelve un estado HTTP Ok: cualquier código por debajo de 400.

• Assertion mode: sustituye los campos clásicos de abajo por un editor de reglas para códigos de estado, tiempo de respuesta, cabeceras o contenido del cuerpo. La captura lo muestra activado con dos reglas: status in [100..399] (completa) y una segunda regla vacía marcada como unfinished; una regla incompleta no participa en el veredicto hasta que la termines o la elimines. HTTP y API son los dos únicos tipos de comprobación con un editor de aserciones funcional; consulta la referencia completa del modo de aserciones para el lenguaje de reglas completo.
• Ignore HTTP Errors (modo clásico): códigos que NO deberían hacer fallar la comprobación, por ejemplo 401, 403, 500; vacío significa que cualquier código 400+ es un error.
• Error on these HTTP statuses: lo contrario: códigos que deberían hacer fallar la comprobación aunque normalmente no lo harían.
• Content check keywords: palabras clave separadas por comas que buscar en la página (se necesita GET).
• Successful content check condition: cómo deciden el veredicto las palabras clave: ANY present (por defecto), ALL present, ANY absent, ALL absent, o ALL absent (fail shows location).
• HTTP Policies: comprobaciones opcionales de cabecera/cookie/contenido; una infracción concluye la comprobación como Down igual que cualquier otro fallo. Los presets Baseline, Strict y API sustituyen toda la selección; ejecuta las políticas como una tarea aparte si quieres una señal más suave que nunca toque las estadísticas de uptime propias de esta tarea.

• TLS Handshake: cuatro interruptores de estrictura (plan de pago): Require valid SSL certificate chain, Require strong TLS protocol (1.2+), Block weak ciphers (128-bit or lower), y Check SSL certificate revocation (consulta CRL/OCSP en línea).
• Expected IPs validation: confirma que el DNS resuelve tu host a una de las IP que listas en cada comprobación; detecta un secuestro, una mala configuración o un registro caducado incluso mientras algún servidor sigue respondiendo.
• Max response size: deja de leer el cuerpo pasado este tamaño; las comprobaciones de contenido, las aserciones y las políticas juzgan entonces solo la parte descargada. Por defecto 1 MB, máximo 10 MB; 0 no lee ningún cuerpo.

Suscripciones de alerta

Compartido por cada tipo de comprobación. Down = el sitio se cayó, Up = se recuperó, Repeat = recordatorios mientras sigue caído. Subscribe all contacts to Up/Down events es un atajo; la tabla da control por contacto, de forma individual o mediante grupos de contactos reutilizables. Una tarea sin suscripciones de alerta se sigue ejecutando y registrando resultados; simplemente nunca avisa a nadie.

Suscripciones de informes

Informes periódicos de uptime, solo por correo. Elige Daily, Weekly o Monthly por contacto; Monthly también incluye resúmenes trimestrales y anuales. El interruptor de suscribir a todos funciona igual que en Suscripciones de alerta.

Ubicaciones de monitorización

• Selector de ubicaciones: busca o navega por el árbol de regiones/países y marca las ubicaciones desde las que comprobar; cada fila muestra los agentes disponibles frente a los seleccionados. "Copy locations from another task" reutiliza un conjunto existente.
• Estrategia de reintento: ante una transición de estado (por ejemplo, de Up a Down), varias ubicaciones la vuelven a verificar antes de aceptar el estado nuevo, protegiendo contra un falso positivo de una ubicación. Opciones: voto por mayoría por defecto; un número especificado de ubicaciones que confirmen Down (añade un deslizador de 1 a 7); sin reintento; acuerdo total de todas las ubicaciones de reintento; o acuerdo total para Down, voto por mayoría para Up.
• If selected locations are unavailable: Selected locations only (por defecto) espera en lugar de arriesgarse a una falsa alerta; Closest locations usa la ubicación disponible más cercana; Any location recurre a cualquier sitio del mundo.

Ejemplo resuelto

Monitorizar una página de inicio de marketing: comprobación HTTP, intervalo de 5 minutos, timeout de 40s, GET, Follow redirects (máx. 20). Palabra clave de comprobación de contenido Contact us con "ANY keyword must be present", así que se detecta un despliegue roto que sirve una página de error. HTTP Policies fijado en Baseline. Ubicaciones dejadas en Todo el mundo con la estrategia de reintento por defecto. El correo del equipo de guardia suscrito a Down, Up y Repeat, y a informes semanales.

Solución de problemas

• Reporta Down pero a ti te carga bien: la red de una única ubicación puede tener un fallo pasajero; eso es exactamente lo que filtra la estrategia de reintento por mayoría por defecto. ¿Sigue oscilando? Revisa DNS Server Selection y confirma que el timeout se ajusta a la latencia normal de esa ubicación.
• Una comprobación de palabra clave de contenido oscila entre Up/Down: el contenido puede variar por caché, personalización o pruebas A/B. Elige una palabra clave presente en cada carga real, y confirma que Successful content check condition coincide con lo que quieres decir.
• Pasó a Down justo después de activar HTTP Policies (sobre todo Strict): Strict espera cabeceras que muchos sitios todavía no han configurado. Arregla las cabeceras, baja a Baseline, o ejecuta las políticas primero como una tarea aparte.
• Una comprobación de contenido o una aserción deja de coincidir en una página grande: Max response size corta el cuerpo, así que nada más allá del corte se lee. Súbelo.
• Una regla de aserción nunca se ejecuta: una regla con un campo, condición o valor vacío se muestra como "unfinished" y no participa en el veredicto. Complétala o elimínala.

Relacionado

• Monitorización de uptime HTTP / de sitio web: la página de producto de este tipo de comprobación.
• Comprobación HTTP instantánea gratuita: ejecuta una comprobación puntual sin necesidad de cuenta.
• Reglas de validación de respuesta en modo de aserciones: el lenguaje de reglas completo detrás de Validación de respuesta.
• Guía de la comprobación DNSBL: el monitor adjunto de lista negra de DNS.
• Guía de caducidad de dominio: el monitor adjunto de caducidad de dominio.
• Guía de caducidad de certificado: el monitor adjunto de caducidad de certificado TLS.
• Guía de Web Risk: el monitor adjunto de malware/phishing.
• Cómo comprobar el tiempo de respuesta del servidor: la versión puntual de lo que mide esta comprobación en cada ejecución.
• Todas las guías de monitorización: la guía de configuración de cada otro tipo de comprobación.