¿Qué es un monitor de disponibilidad web con IA?
Un monitor de disponibilidad web con IA comprueba que un sitio carga, a todas horas y todos los días, y explica cada caída confirmada en lenguaje claro. El código ejecuta las comprobaciones y confirma cada caída desde varias ubicaciones. Después, la IA te dice qué falló y qué revisar primero.
Está pensado para agencias de SEO, equipos internos y desarrolladores cansados de enterarse de una caída por el cliente. Al añadir un sitio se crean automáticamente las comprobaciones por defecto, y tú eliges las páginas críticas, como la de servicios o la de contacto. Las caídas llegan al mismo ciclo que tus problemas de SEO, así que nada se sigue en una aplicación aparte.
¿Por qué afecta una caída al SEO?
Una caída afecta al SEO porque los buscadores tienen que llegar a una página para rastrearla, y los errores de servidor repetidos les indican que deben ir más despacio.
Una caída breve rara vez deja secuelas, ya que los rastreadores cuentan con algún fallo aislado y vuelven. El riesgo crece cuando las respuestas 5xx se repiten o duran mucho. El rastreo se frena, y las URL que siguen inaccesibles pueden acabar saliendo del índice.
Los visitantes lo notan antes que nadie. Quien llega a una página de error desde un resultado de búsqueda o una campaña de pago se va, hagan lo que hagan después los buscadores. El coste real de una caída es el tiempo que pasa entre el fallo y el momento en que alguien actúa, y ese hueco es justo lo que cierra este monitor.
¿Qué debe comprobar un monitor de disponibilidad web además del 200 OK?
Un monitor de disponibilidad web también debe comprobar el DNS, el certificado SSL y el contenido de la página, porque un sitio puede fallar en cualquiera de esas capas mientras las demás parecen sanas.
Un fallo de DNS deja el sitio inalcanzable aunque el servidor esté bien. Un certificado caducado pone un aviso del navegador delante de una página que funciona. Y un 200 OK puede traer una página en blanco, un mensaje de error o una pantalla de mantenimiento, por eso el contenido se revisa en cada carga de página.
Aquí, las cargas de página se hacen cada minuto, el DNS cada 5 minutos y el certificado SSL cada 6 horas. El monitor también señala un nuevo 4xx en una URL que antes funcionaba, los bucles de redirección, los cambios inesperados de DNS y las páginas mucho más lentas de lo normal para el sitio. Un certificado pasa a gravedad alta cuando le quedan menos de 14 días, y a crítica con menos de 3.
¿Cómo evita las falsas alarmas una herramienta de monitoreo web?
Una herramienta de monitoreo web evita las falsas alarmas pidiendo a más de una ubicación que confirme el fallo antes de avisar a nadie. Aquí, una sola comprobación fallida nunca cuenta como caída.
Cada minuto, 1 de las 3 sondas hace su turno. Si falla, las otras 2 comprueban de inmediato, y al menos 2 de 3 deben coincidir para confirmar la caída. Las sondas funcionan en al menos 2 proveedores de alojamiento. Si muchos sitios sin relación fallan desde una misma sonda, el sistema sospecha de esa sonda y retiene las alertas.
Los cortafuegos tienen su propia etiqueta. Un sitio puede responder a una sonda con un 403 o una página de desafío, y entonces el estado dice «Bloqueado, supervisión a ciegas», nunca «Caído». Publicamos las IP de nuestras sondas para que puedas permitirlas.
¿Cómo es una caída confirmada, paso a paso?
Una caída confirmada pasa de una comprobación fallida a una alerta en unos pocos pasos claros, y cada paso queda registrado. Este es un ejemplo de cómo se desarrolla.
La sonda 1 carga la página de inicio y no obtiene respuesta. Las sondas 2 y 3 comprueban de inmediato. La sonda 2 tampoco obtiene respuesta, así que coinciden 2 de 3 y la caída queda confirmada. La alerta sale por correo y en la aplicación, con el tipo de fallo: red.
En la alerta ves qué falló, desde dónde y cuándo. Primero llega una explicación de plantilla, y después la explicación de la IA, con lo que suele significar un fallo de red y qué revisar primero. Cuando el sitio vuelve a cargar, un aviso de recuperación cierra el ciclo, y la caída queda en el historial del sitio.
¿Qué hacer cuando llega una alerta de caída?
Empieza por el tipo de fallo que indica la alerta, porque señala a la persona adecuada. DNS lleva al proveedor de DNS, SSL al certificado y su renovación, red y servidor al alojamiento, aplicación al código o a la última versión publicada, y contenido a la página o su plantilla.
Para un mantenimiento programado, sirve un 503 con la cabecera Retry-After. Esa respuesta indica a los rastreadores que la interrupción es temporal, mientras que una página de mantenimiento con 200 OK puede parecer contenido real. Las horas de silencio y las ventanas de mantenimiento ajustan las alertas a tu calendario.
Un error habitual es vigilar solo la página de inicio. La página de inicio puede cargar perfectamente mientras falla la de contacto o una página de servicio clave, así que elige como URL críticas las páginas que más importan al negocio.
¿Cómo llegan las caídas a los desarrolladores y a los clientes?
Las caídas entran en el mismo ciclo que cualquier otro problema de la plataforma, así que llegan a las personas adecuadas con la prueba adjunta.
Una caída puede convertirse en un ticket del Seguimiento de correcciones, con un responsable y el registro de lo que falló. El historial de disponibilidad e incidentes aparece en el informe del cliente, junto a los problemas de SEO encontrados y corregidos. Donde uses el Agente de recuperación automática opcional, una caída confirmada puede emparejarse con una acción aprobada de antemano, como reiniciar un servicio concreto, para que una persona la apruebe.
¿Cómo ayuda la IA en un monitor de disponibilidad?
La IA explica cada caída confirmada en lenguaje claro, con el tipo de fallo y qué revisar primero, mientras el código confirma la caída en sí.
Ese reparto importa a las 3 de la madrugada. Quien está de guardia lee una explicación clara en lugar de descifrar un error en bruto, y el responsable de cuenta recibe un texto que puede compartir con el cliente. Los recuentos, las horas y los códigos de estado salen de las comprobaciones guardadas, nunca del texto de la IA.
Las alertas nunca esperan a la IA. Primero sale una plantilla y después llega el texto de la IA. Si el servidor de IA va lento o está caído, las alertas de caída siguen saliendo a tiempo.