Monitorización de sitio web gratuita con alertas en tiempo real

¿Por qué vigilar la disponibilidad de tus URLs?

Un uptime del 99,9 % deja margen para 43 minutos de indisponibilidad al mes. Lo difícil es saber cuándo se producen esos cortes. Sin vigilancia automática, un corte se descubre por el email de un cliente, a menudo varias horas después del inicio del incidente. Mientras tanto, el embudo de conversión está roto, los formularios ya no se envían y Googlebot registra errores 5xx.

El mecanismo es sencillo: una petición enviada a intervalos regulares, una respuesta registrada y una alerta cuando se sale de lo esperado.

Cuatro razones para vigilar tus endpoints:

• Detectar antes que los usuarios: un fallo de la aplicación o una caída del hosting sale a la luz en minutos, no con el primer ticket de soporte.
• Proteger el posicionamiento: los 5xx prolongados en páginas indexadas degradan el rastreo y el ranking.
• Cubrir los recorridos críticos: página de pago, endpoint REST, formulario de contacto.
• Acompañar las migraciones: el historial de checks muestra cuándo apareció la regresión.

Cómo usar la monitorización HTTP en 3 pasos

Paso 1: Añadir la URL a vigilar

Introduce la URL completa del endpoint, protocolo incluido:

https://captaindns.com/es/pricing

Empieza por las URLs cuya caída tiene un coste inmediato: página de inicio, checkout, API pública.

Paso 2: Ajustar el intervalo y las condiciones de alerta

En la mayoría de los casos bastan tres ajustes:

• Frecuencia: 5 minutos por defecto. Una expresión cron cubre las necesidades concretas (solo horario laboral, ventana de mantenimiento excluida).
• Código HTTP esperado: cualquier código 2xx por defecto. Indica un código concreto si el endpoint debe devolver exactamente ese, por ejemplo 301 para una redirección o 401 para un endpoint protegido.
• Alertas por email: un interruptor por monitor. Los emails salen hacia la dirección de tu cuenta CaptainDNS, no hay ninguna dirección de destinatario que indicar por monitor. En los planes de pago, un webhook HTTPS puede enrutar hacia Slack, Discord o PagerDuty.

Paso 3: Lanzar un check y leer las métricas

Dispara un check inmediato para validar la configuración. El resultado aparece en unos segundos con el código HTTP, el tiempo de respuesta total y, en su caso, el código de error. El panel agrega después el uptime a 24 h, 7 días y 30 días, el tiempo de respuesta medio y el p95, el heatmap y la lista de incidentes.

Cómo funciona un check HTTP

Cada check recorre cuatro etapas, y cada una puede fallar de forma independiente.

1. Resolución DNS

Se resuelve el nombre de dominio de la URL. Una resolución fallida (NXDOMAIN, SERVFAIL, timeout) marca el check como dns_error y dispara una alerta.

2. Apertura de conexión y negociación TLS

Se abre una conexión TCP hacia la IP resuelta. En HTTPS, el handshake TLS valida la cadena de certificados, la fecha de caducidad y la coincidencia con el hostname. Un certificado caducado o inválido marca el check como tls_invalid.

3. Petición HTTP y lectura de la respuesta

Sale la petición (GET por defecto o el método configurado). CaptainDNS espera hasta el tiempo configurado, 10 segundos por defecto y 30 como máximo. Pasado ese plazo, el check se marca como timeout. Se registran el código HTTP y el tiempo de respuesta total.

4. Evaluación y envío de alertas

Un check es up si el código HTTP es un 2xx, o si coincide exactamente con el código esperado cuando has indicado uno; un 5xx, un código fuera de lo esperado, un timeout o un error de red lo marcan como down. Un paso confirmado de up a down dispara una alerta; la vuelta a up envía un email de recuperación que cierra el incidente.

Monitoriza tu sitio desde varias regiones

Un monitor de una sola región solo ofrece una visión parcial. Si tu única sonda está en Europa y un operador de tránsito transatlántico tiene un problema, el sitio aparece como up mientras tus clientes estadounidenses ya no pueden acceder a él. A la inversa, un incidente de red local cerca de la sonda puede hacer pensar que la caída es global.

CaptainDNS ejecuta los checks desde tres regiones, sobre infraestructura de Fly.io: Europa (eu) para la UE, Reino Unido y el norte de África, Estados Unidos (us) para América del Norte y parte de América Latina, y Asia-Pacífico (apac) para Japón, Corea, el Sudeste Asiático y Oceanía. El número de regiones activables depende del plan: una sola (Europa) en los planes de entrada y hasta tres en los superiores. Consulta los planes y precios.

Tres estrategias de detección de caídas

Tener varias sondas plantea una pregunta: ¿cuántas regiones deben fallar para considerar que el sitio está DOWN?

• Consenso (por defecto): el monitor pasa a DOWN si falla al menos la mitad de las regiones. Filtra los falsos positivos debidos a un incidente de red aislado y notifica rápido una caída real.
• Estricta: basta con una región en DOWN. Adecuada para monitores críticos (pago, API en tiempo real) en los que cualquier flap regional debe notificarse, por breve que sea.
• Unánime: el monitor solo pasa a DOWN si fallan todas las regiones. Adecuada para infraestructuras distribuidas (CDN activo-activo, edge compute) que toleran flaps regionales.

Con una sola región activa, las tres estrategias dan el mismo resultado: la elección solo importa a partir de dos regiones.

Analiza la postura de seguridad de tu sitio

Un monitor de uptime contesta a una sola pregunta: «¿el sitio responde?». No dice nada sobre la calidad de lo que devuelve. Un sitio puede devolver 200 en 80 ms durante meses con un certificado próximo a caducar, un HSTS retirado por un despliegue de reverse-proxy o una CSP pasada a unsafe-inline. La monitorización de postura cubre ese punto ciego: recalcula periódicamente una puntuación de seguridad de las URLs que ya vigilas y te avisa cuando empeora.

Los cinco componentes analizados

• Certificado SSL/TLS: validez, cadena de confianza, fecha de caducidad, versiones de TLS aceptadas.
• HSTS: presencia de la cabecera, duración max-age, cobertura de los subdominios, estado de precarga.
• Cabeceras de seguridad: CSP, X-Frame-Options, Referrer-Policy y demás cabeceras de defensa en profundidad.
• Peso de la página: volumen de los recursos cargados, un indicador básico de rendimiento.
• Reputación (phishing): verificación de la URL vigilada en las bases de amenazas (Google Web Risk, URLhaus, VirusTotal), realizada una vez al día.

Seleccionas los componentes que quieres seguir, como mínimo uno. Desmarcar un componente lo excluye del cálculo sin falsear la puntuación: su peso se redistribuye entre los componentes restantes.

La puntuación sobre 100 en dos áreas

La puntuación global es una media ponderada de Seguridad (80 puntos), que cubre el certificado, el HSTS, las cabeceras y la reputación, y de Rendimiento (20 puntos), que cubre el peso de la página. Cada componente se clasifica en una banda: Excelente, Bueno, Mejorable o Crítico. La seguridad pesa cuatro veces más porque un certificado inválido expone a tus visitantes, mientras que una página pesada solo ralentiza la navegación.

Frecuencia, referencia inicial y alertas

En el primer análisis, CaptainDNS fija una referencia sin enviar ninguna alerta. Después, cada cambio notable dispara un resumen componente por componente, y sale una alerta preventiva antes de que caduque el certificado, por tramos de 30, 14, 7, 3 y 1 día. Una pestaña dedicada muestra la puntuación actual y el historial a 180 días.

El análisis de postura se ejecuta solo desde Europa: el certificado, el HSTS y las cabeceras no varían según el punto de observación. Está disponible a partir del plan Solo, con una frecuencia mínima y un número máximo de monitores por dominio raíz que varían según el plan (consulta los planes y precios).

La puntuación y sus componentes también pueden publicarse en una página de estado pública: eliges, monitor por monitor, los elementos visibles (puntuación sobre 100, certificado, HSTS, cabeceras, peso de la página, reputación). No se publica nada por defecto.

Alertas por email y webhooks

Se envía una alerta en cuanto un check se sale de las condiciones esperadas. Este es el detalle por tipo de error.

Tres salvaguardas contra el ruido

Un sitio que hace flap puede generar decenas de alertas por hora. Tres mecanismos lo impiden:

1. Confirmación con 2 fallos consecutivos: por defecto, ninguna alerta sale antes de dos checks fallidos seguidos. El umbral se ajusta de 1 a 10 fallos en la configuración del monitor.
2. Espaciado progresivo de los recordatorios: una alerta al principio del downtime, después como mucho un recordatorio por hora durante las 24 primeras horas del incidente, y un recordatorio cada 24 horas más allá. Una alerta de recuperación cierra el incidente al volver.
3. Auto-desactivación: un día cuenta como perdido cuando ningún check de la jornada ha tenido éxito. Al 5.º día perdido consecutivo sale un email de aviso; al 7.º, el monitor se desactiva.

El email de alerta contiene la URL afectada, el código HTTP o el tipo de error, la latencia del último check válido, la marca de tiempo en UTC y en hora local, y un enlace al panel. Ningún píxel de tracking.

Webhooks HTTP

El email no permite enrutar los avisos hacia Slack, Discord, PagerDuty o un sistema interno de gestión de incidentes. En los planes de pago, uno o varios endpoints HTTPS reciben los eventos mediante peticiones POST en JSON, firmadas con un secreto compartido para validar el origen en el lado receptor. Cada webhook se suscribe a las categorías que le interesan, tres en total: Monitoring, Deployment y DNS. Las alertas de disponibilidad pertenecen a Monitoring y pueden salir hacia un canal de Slack de ops, mientras que un segundo webhook solo recibe los eventos Deployment. Si falla la entrega, CaptainDNS reintenta con backoff exponencial y registra cada intento.

Métricas de uptime, latencia p95 y heatmap de 30 días

El panel agrega los checks en bruto en seis métricas.

La latencia p95 refleja el rendimiento percibido mejor que la media: la media oculta los picos, mientras que el p95 muestra lo que experimentan tus usuarios en el 5 % de peores casos.

Heatmap de 30 días

El heatmap visualiza los últimos 30 días como una cuadrícula coloreada. Cada celda cubre un día UTC completo, nunca una ventana más fina, y toma su color del uptime de la jornada: verde por encima del 99,5 %, naranja entre el 90 y el 99,5 %, rojo por debajo del 90 % y gris cuando no hay datos.

Historial y retención

Cada check individual se puede consultar durante 30 días en el plan gratis: marca de tiempo, código HTTP, tiempo de respuesta total y, en su caso, código de error. Pasado ese plazo, los checks unitarios se eliminan automáticamente. La retención detallada aumenta en los planes superiores, con un tope de 90 días aplicado a todos los planes. Los agregados diarios (uptime, latencia media) no se purgan; la profundidad de historial visible en una página de estado pública depende del plan, de 30 días en el plan gratis a varios cientos de días por encima. Eliminar un monitor borra todos sus datos.

Casos de uso reales

Caso 1: un despliegue rompe el formulario de contacto

Síntoma: un despliegue del viernes por la tarde pasa a producción. El lunes por la mañana, un cliente avisa de que el formulario de contacto devuelve un error desde el fin de semana.

Diagnóstico: el historial de checks muestra un paso a down con códigos 500 a las 21:12 del viernes, seguido de 61 horas de downtime continuo. La alerta por email del cambio de estado sí salió, pero a una dirección que ya nadie leía.

Acción: enrutar las alertas de la categoría Monitoring hacia un webhook de Slack además del email, y añadir un monitor dedicado al endpoint del formulario en lugar de vigilar solo la página de inicio.

Caso 2: falsa alarma por un incidente de red regional

Síntoma: llega una alerta DOWN a las 3 de la madrugada. El sitio responde con normalidad desde tu equipo.

Diagnóstico: el monitor se ejecuta en tres regiones con la estrategia Estricta. El detalle por región muestra timeout solo desde la sonda apac durante 12 minutos, con eu y us en 200. No es una caída del sitio, sino un incidente de tránsito local.

Acción: pasar ese monitor a Consenso, que exige que falle al menos la mitad de las regiones. Reservar Estricta para los endpoints en los que un flap regional ya es un incidente para el cliente, como una API de pago.

Caso 3: un certificado a punto de caducar el domingo

Síntoma: el sitio responde 200 desde hace semanas y el uptime está al 100 %. Nada indica que el certificado caduca el domingo por la noche.

Diagnóstico: la renovación automática del certificado falló en silencio tras un cambio de configuración del reverse-proxy. Mientras el certificado siga siendo válido, el check HTTP devuelve 200: solo pasará a tls_invalid una vez caducado, es decir, cuando tus visitantes ya vean el aviso de seguridad.

Acción: activar la monitorización de postura en ese monitor. La alerta de caducidad sale por tramos de 30, 14, 7, 3 y 1 día, y la puntuación cae en cuanto el certificado o el HSTS empeoran.

CaptainDNS frente a las herramientas especializadas

CaptainDNS no es una herramienta de monitorización especializada: es un panel de DNS, SPF, DKIM, DMARC y blacklists al que se suman la monitorización HTTP y la postura de seguridad, con un plano de datos operado en la Unión Europea. La elección depende, por tanto, del alcance que necesites. Si solo vigilas uptime y necesitas decenas de monitores gratis, una herramienta especializada como UptimeRobot responde mejor a esa necesidad. Si buscas páginas de estado muy personalizables, BetterStack está más desarrollado en ese terreno. CaptainDNS tiene sentido cuando la vigilancia HTTP prolonga una vigilancia DNS y de correo ya en marcha, y cuando importa que el tratamiento sea europeo. Cuotas y precios exactos en la página de planes y precios.

Cuotas, límites y planes disponibles

El plan gratis incluye 1 monitor HTTP verificado cada 5 minutos desde Europa, es decir, 288 checks al día, con alertas por email ilimitadas, 30 días de historial detallado, heatmap, latencia p95 y 1 página de estado pública, sin tarjeta de crédito. Los planes de pago aumentan el número de monitores, el número de regiones activables, la duración de la retención y el número de webhooks simultáneos, y desbloquean la monitorización de postura a partir de Solo. La tabla completa se mantiene actualizada en la página de planes y precios, que es la fuente de verdad en caso de discrepancia con esta página.

Monitoriza tu sitio desde Europa: cumplimiento y soberanía

La monitorización HTTP es un tratamiento de datos: transmites URLs y, a veces, cabeceras de autenticación. CaptainDNS opera su plano de datos desde la Unión Europea, con sondas europeas en Francia y Alemania, una base de datos PostgreSQL y backups en Francia, y un equipo técnico europeo. Las sondas de Estados Unidos y Asia-Pacífico son opcionales y solo ejecutan los checks: los resultados se almacenan en la base europea, que sigue siendo el almacenamiento primario sea cual sea el plan. El panel no usa ninguna cookie de tracking ni scripts de analítica de terceros. Tú eres el responsable del tratamiento de tus monitores y CaptainDNS actúa como encargado del tratamiento en el sentido del artículo 28 del RGPD; el DPA está disponible a petición.

Límites de la monitorización HTTP

La monitorización HTTP de CaptainDNS no cubre las siguientes necesidades:

• Monitorización TCP pura en puertos no HTTP (SMTP, FTP, base de datos).
• Transacciones multi-paso: recorrido de usuario en varias páginas con aserciones sucesivas.
• Sondas fuera de estas tres regiones (Europa, Estados Unidos y Asia-Pacífico): ni América del Sur, ni África, ni Oriente Medio.
• Endpoints no públicos: una URL detrás de una VPN o de un firewall privado sigue siendo inalcanzable desde nuestras sondas.

Las alertas a Slack, Discord, PagerDuty y Opsgenie no pasan por integraciones nativas: se configuran mediante los webhooks HTTPS, y es el destino el que gestiona el formato final.

FAQ - Preguntas frecuentes

P: ¿Qué es la monitorización de sitio web?

R: La monitorización de sitio web consiste en verificar de forma continua la disponibilidad y la latencia de una URL HTTP. La herramienta envía una petición a intervalos regulares, registra la respuesta y dispara una alerta en caso de fallo. Así detectas la caída antes que tus usuarios.

P: ¿Con qué frecuencia verifica CaptainDNS mi URL?

R: Por defecto, un check HTTP cada 5 minutos en cada uno de tus monitores, es decir, 288 verificaciones al día. Una expresión cron permite personalizar la cadencia: check cada minuto en horario laboral, ventana de mantenimiento excluida.

P: ¿Cómo recibir una alerta cuando mi sitio cae?

R: Activa las alertas por email al crear el monitor: salen hacia la dirección de tu cuenta CaptainDNS, sin destinatario que indicar. En cuanto se confirma un fallo (5xx, timeout, error DNS, certificado TLS inválido), sale una alerta. Los recordatorios se espacian después al menos una hora, y un email de recuperación cierra el incidente cuando el sitio vuelve.

P: ¿Qué significa un uptime del 99,9 %?

R: Un uptime del 99,9 % deja margen para unas 8 horas y 45 minutos de indisponibilidad al año, es decir, 43 minutos al mes. Es el umbral habitual en producción. Al 99,99 %, el presupuesto baja a 52 minutos al año.

P: ¿CaptainDNS es gratis para vigilar mi sitio?

R: El plan gratis incluye 1 monitor HTTP verificado cada 5 minutos, alertas por email ilimitadas, el heatmap de 30 días y la latencia p95, sin tarjeta de crédito. Las cuotas de los demás planes se detallan en la página de precios.

P: ¿Puedo monitorizar una URL autenticada o un endpoint privado?

R: Sí, siempre que la URL sea pública. Las cabeceras HTTP personalizadas (Authorization, X-API-Key) permiten consultar un endpoint protegido por token. Una URL detrás de una VPN o de un firewall privado sigue siendo inalcanzable desde nuestras sondas.

P: ¿Cómo compartir mis resultados de monitorización?

R: Vincula tu monitor a una página de estado pública de CaptainDNS. Expone el uptime, la latencia y el historial de incidentes a tus clientes, sin abrirles tu panel privado.

P: ¿Qué es la puntuación de postura de seguridad?

R: Es una evaluación sobre 100 recalculada periódicamente a partir de cinco componentes: certificado SSL/TLS, HSTS, cabeceras de seguridad, peso de la página y reputación (phishing). Se reparte en Seguridad (80 puntos) y Rendimiento (20 puntos), y te avisa en cada regresión o antes de que caduque el certificado. Disponible a partir del plan Solo.

P: ¿Qué componentes analiza la postura y con qué frecuencia?

R: Certificado SSL/TLS, HSTS, cabeceras de seguridad HTTP, peso de la página y reputación (phishing). Eliges los componentes que quieres seguir (al menos uno) y la frecuencia, de una vez por hora a una vez al día según el plan. El peso de la página y la reputación se miden una vez al día como máximo.

Herramientas complementarias

Recursos útiles

• Google SRE Book: Service Level Objectives (definición de referencia de los SLA, SLO y presupuestos de error que hay detrás del 99,9 %)
• RFC 6797 (especificación de HTTP Strict Transport Security, uno de los componentes de la puntuación de postura)
• MDN: Content-Security-Policy (documentación de la cabecera CSP y de sus directivas)
• Documentación de Let's Encrypt (renovación automática y vida útil de los certificados TLS)
• CA/Browser Forum (organismo que fija los requisitos básicos de los certificados públicos, incluida su duración máxima de validez)
• Fly.io: regiones (lista de las regiones de la infraestructura en la que se ejecutan las sondas)