La monitorización de uptime de una web envía una petición a tu sitio con una frecuencia fija y comprueba la respuesta. Si la respuesta es incorrecta, lenta o no llega, recibes una alerta. Suena sencillo, y lo es. El valor está en los detalles: con qué frecuencia compruebas, qué cuenta como fallo, cómo se confirma un fallo y con qué rapidez se entera la persona adecuada.
Uptimecheck ejecuta comprobaciones HTTP(S), ping y de puertos cada 1, 2, 5, 10, 15 o 30 minutos o cada hora. Cada comprobación registra el código de estado y el tiempo de respuesta, así que ves tanto las caídas como los periodos de lentitud. Si antes quieres el contexto, lee qué es la monitorización de uptime y por qué importa.
Tipos de comprobación
HTTP(S): solicita una URL con GET, POST u otro método, envía tus propias cabeceras y cuerpo, y comprueba el código de estado, una palabra clave o campos JSON de la respuesta.Ping: confirma que un host responde en la red, con el tiempo de ida y vuelta.Puerto: comprueba que un servicio, como un servidor de correo o una base de datos, acepta conexiones.
Para recorridos de varias páginas, como iniciar sesión o completar una compra, usa la monitorización de flujos.
Por qué comprobar cada minuto, y comprobar dos veces
Una caída cuesta dinero cada minuto. Si tu checkout responde 503 a las 03:12 y nadie se da cuenta hasta la primera incidencia de soporte, has perdido horas en lugar de minutos. Nuestra guía sobre el coste de las caídas de una web repasa las cifras.
Uptimecheck comprueba desde Estocolmo, Londres y Nueva York, y confirma cada fallo desde una segunda ubicación antes de abrir un incidente. Así se evitan falsas alarmas por una sola petición perdida o un breve corte de red, mientras que una caída real te llega en uno o dos minutos. Nuestra guía para reducir las falsas alertas explica por qué importa.
De la comprobación fallida a la solución
03:12: la comprobación de northwind.shop/checkout devuelve 503.03:12: la segunda comprobación también falla. Se abre un incidente con la respuesta fallida y una captura de lo que veían los visitantes.03:13: el desarrollador de guardia recibe una notificación push en el móvil y el canal del equipo recibe los detalles en Slack.03:19: las comprobaciones vuelven a pasar. Se envía un aviso de recuperación con el tiempo total de caída.
Las alertas llegan por correo electrónico, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks y notificaciones push en el móvil, en todos los planes. Consulta alertas y notificaciones para el enrutamiento y la escalada, la gestión de incidentes para lo que pasa después de la alerta, y combina la monitorización con una página de estado para que los clientes sepan qué ocurre sin abrir una incidencia.
Tiempos de respuesta desglosados por fases
Cada comprobación HTTP guarda su tiempo de respuesta, desglosado en DNS, conexión, TLS, servidor y descarga. Una fase de servidor lenta apunta a tu aplicación; un DNS o un TLS lentos apuntan a la infraestructura. Los gráficos muestran la mediana, el percentil 95 y la media, para que una cola lenta no quede oculta tras una buena media. Más información sobre el tiempo de respuesta de una web.
Fija un límite, por ejemplo 2.000 ms, y recibirás una alerta de lentitud cuando tres comprobaciones seguidas superen ese tiempo, y otra cuando la web vuelva a ir rápida. El tiempo lento no cuenta como caída.
La página del monitor muestra sus últimas comprobaciones. Tres o más comprobaciones iguales seguidas se agrupan en una línea, como «OK · 200 × 18» con el rango de tiempos de respuesta, y se despliegan para mostrar cada comprobación. Un fallo nunca se agrupa con una serie de comprobaciones correctas, y la segunda comprobación que confirma un fallo mantiene su propia línea. Si un monitor que no está en pausa no se ha comprobado en el doble de su intervalo, la página indica «Sin datos recientes» con la hora de la última comprobación, para que un estado antiguo nunca pase por actual.
Comprueba que la página funciona de verdad
Una página puede responder 200 y aun así estar rota: una lista de productos vacía, un mensaje de error, una página de mantenimiento. Añade comprobaciones de respuesta que deben cumplirse todas:
Estado esperado: códigos o rangos, como 200-299 o 200,301.Palabra clave: texto que la página debe o no debe contener, como «Añadir al carrito».JSON y cabeceras: para APIs, un campo como $.status es igual a ok, o una cabecera que debe estar presente.
Los monitores HTTPS también leen el certificado y te avisan antes de que caduque. Consulta la monitorización SSL.
Configura tu primer monitor
Añade la URL, elige el tipo de comprobación, define qué cuenta como respuesta válida y elige a qué canales avisar. «Petición de prueba» muestra la respuesta antes de guardar, y la primera comprobación se ejecuta al momento. La mayoría de los equipos empiezan con tres monitores: la página de inicio, la página de conversión más importante (checkout, registro o inicio de sesión) y el endpoint principal de la API. ¿Vienes de UptimeRobot, Better Stack, Pingdom o StatusCake? Importa tus monitores con su configuración y revísalos todos antes de que se cree nada.
Qué cuenta como caída
Una comprobación falla cuando la petición agota el tiempo de espera, se rechaza la conexión, el certificado no es válido, el código de estado no es el esperado o no se cumple una comprobación de respuesta. El uptime es la proporción de tiempo sin una caída confirmada, y las ventanas de mantenimiento no cuentan en contra. Los informes muestran el uptime de cada monitor para cualquier periodo frente a tu objetivo de SLA, con exportación a CSV.
Los planes empiezan en 9 € al mes con facturación anual o 12 € con facturación mensual, IVA no incluido, con comprobaciones cada minuto en todos los planes de pago, o gratis para 5 monitores comprobados cada 5 minutos. Compara monitores, páginas de estado e historial (1, 2 o 3 años) en la página de precios, echa un vistazo a la demo en vivo sin registrarte o empieza una prueba gratis de 14 días sin tarjeta.