La mayoría de los dueños de sitios web no se preguntan «¿está activo mi sitio?» hasta que un cliente les dice que no lo está. La monitorización de la disponibilidad adelanta ese momento. Esta página sigue una caída desde la primera comprobación fallida hasta la recuperación y muestra qué puedes y qué no puedes aprender por el camino.

Da por hecho que la monitorización ya está configurada. Si no lo está, empieza con la guía Cómo monitorizar la disponibilidad de un sitio web.

Qué te dice una comprobación de disponibilidad

Una comprobación de disponibilidad solicita una dirección según un calendario y examina la respuesta. Te dice si la dirección respondió, cómo respondió el servidor y cuánto tardó. No te dice qué falla.

Una dirección monitorizada es una URL exacta. Si monitorizas https://shop.example.com/, esa es la única página que se comprueba. El proceso de pago, la página de inicio de sesión y la API de otra dirección no quedan cubiertos a menos que los añadas como sitios web propios.

Una caída a modo de ejemplo

Lo siguiente es un ejemplo inventado, no una historia de cliente. Una pequeña tienda monitoriza https://shop.example.com/ cada 3 minutos, y las alertas van a un buzón compartido que lee el dueño.

  1. La primera comprobación fallida. El servidor empieza a responder con un error. La comprobación se registra como un fallo.
  2. Confirmación. UptimeWire no alerta por un solo fallo. Repite la comprobación poco después. Solo si el fallo continúa se abre un incidente.
  3. La alerta. El dueño recibe un mensaje de que el sitio web está caído, con la hora en que se abrió el incidente.
  4. La investigación. El dueño abre el sitio web, luego el panel del alojamiento, y descubre que el servidor de la base de datos se reinició.
  5. Recuperación. Cuando la dirección vuelve a responder, se confirma la recuperación y llega un segundo mensaje.
  6. La revisión. Unos días después el dueño abre el historial, ve el incidente y su duración, y lo compara con los anteriores.

Ninguno de estos pasos es instantáneo. La alerta llega después del intervalo de comprobación, de las comprobaciones repetidas y de la entrega del mensaje. Ninguna herramienta de monitorización puede prometer un tiempo de detección exacto.

Cómo leer la alerta

Una alerta de caída dice que una dirección monitorizada dejó de responder correctamente y que el fallo se confirmó. No dice por qué. Lo que sí te da es un punto de partida:

  • Qué sitio web. La alerta nombra la dirección monitorizada.
  • Cuándo empezó. El incidente tiene una hora de inicio, que te ayuda a relacionarlo con un despliegue, una copia de seguridad o un aviso del proveedor.
  • Qué vio la comprobación. Un estado de error, un tiempo de espera agotado o la ausencia total de respuesta apuntan a lugares distintos donde buscar. El artículo sobre códigos de estado HTTP explica los más comunes.

Las alertas por correo electrónico y Telegram están disponibles en todos los planes. Los webhooks, Discord, Slack y Teams también transportan mensajes de caída y recuperación, según el plan. Consulta Precios para saber qué plan incluye cada canal.

Qué revisar primero

UptimeWire no diagnostica la causa, así que los primeros minutos son tuyos. Un orden breve que sirve para la mayoría de los sitios web pequeños:

  1. Abre tú mismo la dirección, en una ventana privada del navegador. Si carga, el problema puede ser breve o limitado a algunos visitantes.
  2. Mira el estado que devuelve tu servidor. Un error 5xx apunta al servidor o a la aplicación. Un tiempo de espera agotado apunta a la red o a un servidor sobrecargado.
  3. Revisa el proveedor de alojamiento. Busca un aviso de estado o un reinicio.
  4. Revisa qué cambió. Un despliegue, una actualización de un plugin o un cambio de configuración poco antes del incidente es una causa habitual.
  5. Confirma la recuperación una vez que actúes, y espera al mensaje de recuperación.

Note

UptimeWire te dice que el problema existe. No encuentra la causa y no arregla nada.

Usar el historial tras la recuperación

Cuando el incidente termina, el historial convierte una hora mala en información:

  • Inicio y duración. Cuánto tiempo estuvo no disponible el sitio web, para compararlo con lo que esperabas.
  • Patrones. Los fallos a la misma hora del día sugieren algo programado, como una copia de seguridad o una tarea pesada.
  • Tiempo de respuesta en torno al incidente. Un sitio web que iba lento antes de fallar apunta a un problema de recursos más que a una rotura repentina.

Cuántos días de historial puedes ver depende de tu plan. Las entradas del glosario Disponibilidad (uptime) y Tiempo de inactividad explican cómo se cuentan estas cifras, y la Calculadora de uptime muestra cuánto tiempo de inactividad permite un porcentaje dado.

Lo que la monitorización de la disponibilidad no cubre

Sé claro con los límites, para que una bandeja de entrada tranquila no te dé una falsa tranquilidad.

  • Una respuesta sana no es un sitio web que funciona. Una página puede responder con normalidad mientras el proceso de pago, el inicio de sesión o un servicio del backend están rotos. Puedes añadir una regla que busque un texto concreto en la página, lo que reduce la brecha pero no la cierra.
  • Una dirección no es todo el sitio web. Otras páginas, subdominios y API necesitan sus propias entradas.
  • La detección no es instantánea. El intervalo marca con qué frecuencia se solicita la dirección. La confirmación y la entrega añaden tiempo.
  • No hay pruebas basadas en un navegador. UptimeWire no ejecuta recorridos de usuario, como añadir un artículo a un carrito.
  • No hay análisis de causa raíz. La alerta dice qué falló y cuándo, no por qué.

Cuándo encaja

Este enfoque encaja con un sitio web del que dependen las personas, donde el equipo necesita enterarse rápido de un fallo y ver después qué pasó: una tienda, una página de reservas, un sitio corporativo, un sitio de documentación. No sustituye a probar las funciones de una aplicación.