Para monitorizar la disponibilidad de un sitio web necesitas tomar cuatro decisiones: qué dirección vigilar, con qué frecuencia, a quién avisar y qué cuenta como un fallo. Esta guía las aborda por orden y muestra cómo se ve cada una en UptimeWire. El razonamiento sirve para cualquier herramienta de monitorización, así que también puedes usarlo para valorar otras.
Si prefieres leer antes el contexto, consulta la Guía completa de monitorización de la disponibilidad de sitios web.
Qué detecta la monitorización de la disponibilidad
Un monitor de disponibilidad solicita tu dirección según un calendario y revisa la respuesta. Detecta:
- Un servidor caído o que no responde.
- Un servidor que responde con un error, como
500o503. - Un dominio que ya no se resuelve.
- Una redirección que entra en bucle o nunca termina.
- Una conexión que agota el tiempo de espera.
No detecta los problemas que dejan la respuesta con buen aspecto, como un proceso de pago roto detrás de una página normal. Más adelante en esta guía verás cómo reducir esa brecha.
Elige la dirección exacta que vas a monitorizar
Elige la dirección que usaría realmente un visitante, escrita completa, con https://.
- Usa la dirección final. Si
http://example.comredirige ahttps://www.example.com, monitoriza la segunda. El monitor sigue las redirecciones, pero la dirección final es la que importa, y te ahorra un paso. - Una dirección vigila una página. Monitorizar
https://example.com/no cubrehttps://shop.example.com/nihttps://example.com/api/. En UptimeWire, un sitio web es una dirección exacta. Añade por separado cada una de las importantes. - Prefiere una página que demuestre algo. Una página de inicio estática puede cargar mientras la aplicación que hay detrás está rota. Si tienes una página de estado ligera que toca la base de datos, monitorízala también.
- Evita las direcciones que exigen iniciar sesión. Un monitor no puede iniciar sesión. Una página que responde
401o403a desconocidos se notifica como un fallo.
Tip
Elige la dirección, ábrela en una ventana privada del navegador y comprueba que carga sin iniciar sesión. Si no carga, el monitor tampoco la verá.
Entiende los códigos de estado HTTP
En cada comprobación, el monitor lee el código de estado. El artículo sobre códigos de estado HTTP los explica por completo. La versión corta para la monitorización:
| Respuesta final | Se cuenta como |
|---|---|
| 200 a 299 | Disponible |
| 300 a 399 | Disponible (una redirección final que no se sigue) |
| 400 a 499, incluidos 401 y 403 | Fallo |
| 500 a 599 | Fallo |
| Sin respuesta, o tiempo de espera agotado | Fallo |
| Demasiadas redirecciones | Fallo |
UptimeWire sigue las redirecciones, hasta un límite de cinco, y luego juzga la respuesta final. Un estado de 200 a 399 significa disponible. Cualquier otro es un fallo.
Important
Un 200 significa que el servidor respondió. No significa que la página sea correcta. Un sitio puede devolver 200 con un mensaje de error en el cuerpo, o una página vacía. La regla de texto de página que se describe más abajo sirve para eso.
Elige un intervalo de comprobación
El intervalo es el tiempo que transcurre entre comprobaciones. Un sitio que falla solo se puede detectar con una comprobación que se ejecute mientras está caído, así que un intervalo más corto encuentra los problemas antes.
UptimeWire ofrece estos intervalos: 1 minuto, 3 minutos, 5 minutos, 15 minutos, 30 minutos, 1 hora, 6 horas, 12 horas y 1 día. Tu plan fija el más corto que puedes elegir:
| Plan | Intervalo más corto |
|---|---|
| Free | 5 minutos |
| Starter | 3 minutos |
| Business | 1 minuto |
| Agency | 1 minuto |
Los intervalos más cortos de lo que permite tu plan aparecen en el formulario bloqueados, junto con el plan que los desbloquea.
Cómo elegir:
- Tienda, reservas o servicio de pago: el intervalo más corto que permita tu plan.
- Sitio de empresa o documentación: 5 minutos es más que suficiente.
- Un sitio del que solo necesitas saber que no ha desaparecido en días: de 30 minutos a una hora.
El intervalo no es lo mismo que el tiempo de detección. Una comprobación fallida se repite antes de convertirse en un incidente, como se explica más abajo.
Configura la monitorización en UptimeWire
Estos pasos corresponden al producto actual. Las pantallas pueden cambiar, así que toma los nombres como orientación.
- Crea una cuenta en app.uptimewire.com.
- Confirma tu dirección de correo. No puedes añadir un sitio web hasta que la dirección esté confirmada. La monitorización empieza después.
- Inicia el primer sitio web. Una configuración breve te pregunta tres cosas, una pantalla cada vez, y muestra un resumen de lo que se va a hacer.
- Sitio web. La dirección que vigilar y un nombre.
- Comprobaciones. El intervalo, con cuántos días de antelación avisar del vencimiento del certificado y del dominio, y una regla opcional de texto de página.
- Alertas. La dirección de correo que recibe las alertas de este sitio web.
- Pulsa «Empezar a monitorizar». También puedes usar «Empezar ahora», que aplica los ajustes que ya están en la página, u omitir la configuración y añadir un sitio web más tarde. Los ajustes se pueden cambiar después.
- Observa la primera comprobación. Una pantalla posterior muestra el primer resultado cuando llega: en curso, activo, no se pudo abrir o tarda más de lo esperado.
Cada sitio web que añades también recibe comprobaciones de certificado, de vencimiento del dominio y de DNS. Se ejecutan con sus propios calendarios, al margen del intervalo que elegiste.
Configura el correo de las alertas
El correo de las alertas pertenece al sitio web. Es adonde van los mensajes de caída y de recuperación, y también los avisos sobre el certificado, el dominio y el DNS.
Usa una dirección que alguien lea. Un buzón compartido que nadie abre te da una monitorización a la que nadie reacciona. Para un equipo, usa una dirección de grupo para que la alerta no dependa de una sola persona.
Añade más canales de notificación
El correo es el predeterminado. Los demás canales son opcionales y se configuran una sola vez, para toda la cuenta, en los ajustes de notificaciones de tu perfil. Después se aplican a todos los sitios web.
Los canales que puedes usar dependen de tu plan. Consulta Precios para ver la lista actual.
No todos los canales llevan todos los mensajes:
| Mensaje | Correo | Telegram | Webhook, Slack, Discord, Teams |
|---|---|---|---|
| Caída y recuperación | Sí | Sí | Sí, donde tu plan incluya el canal |
| Avisos de certificado, dominio y DNS | Sí | Sí | No |
Note
Solo el correo y Telegram llevan los avisos de certificado, dominio y DNS. Si dependes de un canal de chat para las caídas, mantén también el correo activado, o no te enterarás de que un certificado está a punto de caducar.
Cómo funciona la confirmación de incidentes
Cuando una comprobación falla, UptimeWire no avisa de inmediato. Repite la comprobación poco después y abre un incidente solo si los fallos continúan. Cuando hay un segundo punto de comprobación disponible, también se le puede preguntar si ve el mismo fallo.
Es algo deliberado. Los cortes breves, un paquete perdido por el camino o un reinicio rápido provocarían falsas alarmas, y las falsas alarmas enseñan a la gente a ignorar las reales. Cuando se abre un incidente, recibes una notificación. Cuando el sitio vuelve a responder, se confirma la recuperación y también te avisan de eso.
El coste es tiempo. La alerta llega después del intervalo, de las comprobaciones repetidas y de la entrega del mensaje. Ningún monitor puede prometer un tiempo de detección exacto, y una guía que lo haga está vendiendo humo.
Añade una regla de texto de página cuando 200 no basta
Si tu sitio puede responder 200 con un contenido incorrecto, añade una regla de texto de página a la comprobación. En el paso «Comprobaciones» puedes elegir que se trate como un fallo cuando falte un texto determinado en la página, o cuando aparezca.
Por ejemplo, un texto que siempre está en tu página, como una frase del pie de página, te dice que se cargó la página real. Un texto como «Error establishing a database connection» te dice que se está mostrando la página de error.
Lo que debes saber:
- El texto debe coincidir exactamente con cómo aparece en el código fuente de la página, mayúsculas incluidas.
- Solo se lee el primer megabyte de la página final.
- Un texto ausente se trata como cualquier otro fallo: se repite y se confirma antes de avisarte.
- Usa el botón «Probar este texto» antes de guardar, para asegurarte de que la regla se comporta como esperas.
Revisa los primeros resultados
Después de la primera comprobación, fíjate en tres cosas:
- El estado. ¿El sitio web está activo? Si dice que no pudo abrir la dirección, compárala con lo que escribes en un navegador.
- El tiempo de respuesta. Anota la cifra. Es tu valor de referencia, y los cambios posteriores cobran sentido frente a ella. Consulta tiempo de respuesta para ver qué incluye la cifra.
- El estado del certificado, el dominio y el DNS. Estas comprobaciones se ejecutan con sus propios calendarios, así que pueden mostrar un resultado un poco después de la primera comprobación.
Si la primera comprobación falla y el sitio funciona en tu navegador, las causas habituales son un error tipográfico en la dirección, una página que exige iniciar sesión, un cortafuegos que bloquea las solicitudes automatizadas o una redirección que entra en bucle.
Interpreta el historial de monitorización
A lo largo de los días, el historial muestra patrones que una sola comprobación no puede mostrar:
- Fallos aislados a la misma hora del día apuntan a algo programado: una copia de seguridad, un despliegue, una tarea pesada.
- Un tiempo de respuesta que sube poco a poco apunta a una base de datos que crece, un proceso con fugas o un plan demasiado pequeño.
- Los incidentes largos muestran dónde es lenta tu recuperación, no solo tu detección.
- Ningún incidente durante semanas es un buen resultado. También es un motivo para comprobar una vez que las alertas siguen llegando.
La disponibilidad es la proporción del período en que el sitio estuvo disponible. Úsala como una tendencia para ti, no como una promesa a los clientes.
Prueba tus notificaciones
No esperes a una caída real para descubrir que una alerta va a spam o a la persona equivocada.
- Añade un sitio web de prueba con una dirección que no exista, o usa una regla de texto de página que sepas que va a fallar.
- Espera a que se abra el incidente.
- Comprueba que el correo llega y que los demás canales que activaste también entregan el mensaje.
- Comprueba el mensaje de recuperación después de arreglar la prueba.
- Elimina el sitio web de prueba.
Revisa las carpetas de spam y los filtros. Si un equipo recibe la alerta, comprueba que cada persona la recibe de verdad.
Errores comunes de monitorización
- Monitorizar solo la página de inicio. El pago, el inicio de sesión y la API pueden romperse mientras la página de inicio está bien.
- Elegir la dirección equivocada. Monitorizar una dirección que redirige, exige iniciar sesión o está en caché de una CDN puede ocultar problemas reales.
- Un buzón de alertas sin leer. Una monitorización que nadie lee no es monitorización.
- Fiarse demasiado del
200. Añade una regla de texto o monitoriza una dirección más profunda. - Suponer que una dirección cubre un dominio. No cubre los subdominios ni otras rutas.
- Configurar una vez y no probar nunca. Comprueba el camino de las alertas de vez en cuando.
- Depender solo de un canal de chat. Los avisos de certificado llegan únicamente por correo y Telegram.
Lista de comprobación de la configuración
- La dirección exacta, con
https://, carga sin iniciar sesión. - El intervalo se ajusta al coste de una caída y lo permite tu plan.
- El correo de las alertas lo lee una persona.
- Los canales adicionales están conectados en el perfil, si los quieres.
- Hay una regla de texto de página donde un simple
200no basta. - Llegaron una alerta de prueba y su recuperación.
- Cada dirección importante está añadida como un sitio web propio.
- Los avisos de certificado, dominio y DNS están configurados con la antelación que necesitas.
A continuación, aprende a evitar una de las caídas más prevenibles: Cómo evitar que caduque un certificado SSL.