Puedes monitorizar una web gratis de cuatro maneras: el plan gratuito de un servicio de monitorización, un pequeño script en un servidor que ya tengas, un workflow programado en un servicio de CI como GitHub Actions y comprobadores puntuales gratuitos para cuando algo ya parece ir mal. Para una web personal o un proyecto paralelo, suele bastar. Paga por la monitorización cuando la caída te cueste dinero o reputación, cuando necesites enterarte en uno o dos minutos o cuando haya que despertar y mantener informada a más de una persona.
Esta guía repasa cada opción gratuita, lo que hace bien, lo que se le escapa sin avisar y cómo saber cuándo se te ha quedado pequeña.
Qué tiene que hacer la monitorización de una web
Uses lo que uses, gratis o de pago, júzgalo por cuatro tareas. Si falta una, todavía no tienes monitorización: tienes una esperanza.
Comprobar con regularidad y desde fuera. Una comprobación desde el mismo servidor que aloja la web puede salir bien mientras los visitantes no consiguen conectarse. El intervalo es el tiempo máximo que puedes pasar sin enterarte de una caída.
Decidir qué cuenta como caída. Un timeout, una conexión rechazada, un 5xx, un certificado no válido o una página que responde 200 pero muestra un error. Consulta qué es la monitorización de uptime para ver los detalles.
Llegar a una persona. Una alerta que acaba en la carpeta de spam a las 03:00 no es una alerta. Tiene que llegar a un sitio que de verdad mires, y después debe llegar un aviso de recuperación.
Guardar un registro. ¿Cuándo se cayó, durante cuánto tiempo y con qué frecuencia pasa? Sin historial no puedes responder a un cliente, comprobar el SLA de un proveedor de hosting ni detectar un patrón.
Opción 1: el plan gratuito de un servicio de monitorización
Varios servicios de monitorización ofrecen un plan gratuito, y es la forma más rápida de cubrir las cuatro tareas para un puñado de URL. Los límites varían de un servicio a otro y cambian con el tiempo, así que lee la página de planes y las condiciones actuales en lugar de un artículo comparativo. Estas son las preguntas que merece la pena hacerse:
¿Con qué frecuencia comprueba? Los planes gratuitos suelen comprobar con menos frecuencia que los de pago. Cada 5 minutos significa que una caída puede durar hasta 5 minutos antes de la primera comprobación fallida.
¿Se confirma el fallo antes de la alerta? Una segunda comprobación desde la misma u otra ubicación filtra una única petición perdida. Sin ella, cuenta con falsas alertas.
¿Qué canales de alerta incluye? ¿Solo email, o también chat y notificaciones push en el móvil?
¿Puede comprobar el contenido? El código de estado por sí solo no detecta una página que carga pero está rota. Busca comprobaciones de palabras clave o de la respuesta.
¿Cuánto tiempo se guarda el historial y se permite el uso comercial? Algunos planes gratuitos están pensados solo para proyectos personales.
Opción 2: un script en un servidor que ya tienes
Si tienes un servidor o un VPS en un sitio distinto de donde se ejecuta la web, una línea en el crontab te da una comprobación básica cada 5 minutos:
*/5 * * * * curl -fsS -m 10 -o /dev/null https://example.com/ || echo «example.com failed at $(date -u)» | mail -s «Site down» you@example.com
-f hace que curl falle ante errores HTTP, -m 10 se rinde a los 10 segundos y el correo solo sale cuando la petición falla. No cuesta nada y controlas cada detalle. Pero también tiene carencias reales:
Nadie vigila al vigilante. Si ese servidor se cae, o se rompe su configuración de correo, las comprobaciones se detienen y no te enteras de nada. El silencio es idéntico a una web en perfecto estado.
El correo enviado desde un servidor suele acabar en spam si el dominio remitente no tiene configurados SPF, DKIM y DMARC. Nuestra guía sobre SPF, DKIM y DMARC explica por qué.
Cada fallo es una alerta, y recibes una cada 5 minutos mientras dure la caída, pero ningún aviso de recuperación.
Sin historial. A menos que registres cada resultado y montes un informe, no podrás decir cuál fue tu uptime el mes pasado.
Nunca ejecutes la comprobación en el mismo servidor que la web. Un servidor al que no se puede llegar desde internet normalmente sí puede llegar a sí mismo.
Opción 3: un workflow de CI programado
¿No tienes un servidor de sobra? Un workflow programado en GitHub Actions puede ejecutar la misma comprobación. Si un paso falla, falla la ejecución y GitHub te avisa:
name: Site check
on:
schedule:
– cron: ‘7,22,37,52 * * * *’
jobs:
check:
runs-on: ubuntu-latest
steps:
– run: curl -fsS -m 10 -o /dev/null https://example.com/
Funciona, con los límites que GitHub documenta para el evento schedule:
El intervalo más corto es una vez cada 5 minutos.
Las ejecuciones programadas pueden retrasarse cuando GitHub Actions está saturado, sobre todo al principio de cada hora, y algunos trabajos en cola pueden descartarse. Por eso el ejemplo evita el minuto 0.
En un repositorio público, los workflows programados se desactivan tras 60 días sin actividad en el repositorio.
Las notificaciones van al usuario que modificó por última vez la programación cron en el archivo del workflow, no a un equipo.
Un workflow es un buen parche para un proyecto paralelo. Como monitorización de algo por lo que la gente paga, una alerta que puede llegar tarde, o no llegar, es un eslabón débil. La herramienta de expresiones cron muestra cuándo se ejecuta de verdad una programación como la de arriba.
Opción 4: comprobadores gratuitos para cuando algo parece ir mal
Los comprobadores puntuales no vigilan nada, pero responden en segundos a las primeras preguntas de un incidente. Todos son gratuitos y no necesitan cuenta:
Is it down? comprueba cualquier web una vez desde nuestro servidor, para que distingas entre «caída para todos» y «solo me pasa a mí».
Comprobador SSL muestra cuándo caduca un certificado, quién lo emitió y la cadena completa.
Comprobador de caducidad de dominios lee la fecha de caducidad y el registrador en el registro.
Consulta DNS y el comprobador de SPF, DKIM y DMARC muestran lo que publica tu dominio en este momento.
Los comprobadores son un complemento, no un sustituto: solo miran cuando se lo pides, y solo se lo pides cuando ya sospechas que hay un problema. La checklist para cuando tu web se cae muestra dónde encaja cada uno.
Dos fechas de caducidad que los sistemas gratuitos olvidan
Las caídas por certificados y dominios caducados están entre las más fáciles de evitar, y una simple comprobación de «¿está en línea?» solo las detecta cuando ya han ocurrido.
Certificados. Let’s Encrypt dejó de enviar emails de caducidad el 4 de junio de 2025, así que si tu tarea de renovación falla, nadie te avisa. Además, la vigencia de los certificados es cada vez más corta, lo que supone más renovaciones que pueden fallar; consulta qué implica que los certificados duren menos.
Dominios. Los recordatorios de renovación llegan a la dirección de email de la cuenta del registrador, que a menudo es antigua o de alguien que ya no está. Activa la renovación automática y comprueba que la tarjeta registrada sea válida.
Cuándo ha llegado el momento de pagar
La monitorización gratuita está bien mientras enterarte tarde de una caída sea una molestia y no una pérdida. Estas son las señales de que ya no es así:
La web genera dinero cada minuto. Una tienda, un sistema de reservas o un producto SaaS. Ponle cifra con la calculadora del coste de las caídas; si una hora de caída cuesta más que un año de monitorización, la decisión está tomada.
Prometes una cifra de uptime. Un 99,9% permite 43 minutos y 49 segundos de caída al mes, como muestra la calculadora de uptime. Con un intervalo de 5 minutos, solo la detección puede consumir buena parte de ese margen.
Hay más de una persona implicada. Las alertas tienen que llegar a quien esté de guardia, escalar cuando nadie responde y llegar al chat del equipo.
Los clientes preguntan «¿solo me pasa a mí?». Una página de estado que se actualiza a partir de tus comprobaciones les responde antes de que abran un ticket.
Gestionas webs de clientes. Necesitas informes que muestren qué pasó y cuándo, sin tener que montarlos a mano.
Lo importante no es la página de inicio. El checkout, el login, una API o la copia de seguridad nocturna necesitan comprobaciones que una línea de curl no resuelve bien: flujos de varios pasos, comprobaciones de JSON y heartbeats.
Qué obtienes pagando con Uptimecheck
Uptimecheck tiene un plan gratuito: cada espacio de trabajo nuevo empieza con una prueba gratuita de 14 días de Professional, sin tarjeta, y después pasa a Free salvo que elijas un plan. Free comprueba 5 monitores cada 5 minutos, con 1 página de estado y hasta 3 canales de alerta, como email, Slack o Microsoft Teams, y permite el uso comercial. Todos los planes de pago incluyen:
Comprobaciones de uptime cada minuto desde Estocolmo, Londres y Nueva York, con cada fallo confirmado desde una segunda ubicación antes de alertar, y comprobaciones de palabras clave, JSON y cabeceras en la respuesta.
Alertas por email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks y notificaciones push en el móvil, con un aviso de recuperación cuando la web vuelve.
Recordatorios de caducidad de SSL y dominios, heartbeats para cron jobs y páginas de estado que se actualizan solas.
Historial de uptime, tiempos de respuesta e incidentes durante 1, 2 o 3 años según el plan.
Los planes cuestan 12 €, 39 € o 92 € al mes con facturación mensual, o 9 €, 29 € o 69 € al mes con facturación anual, IVA excl., vendidos a través de Link (Stripe), nuestro revendedor. Start incluye 15 monitores de uptime, Professional 100 y Business 250. Compáralo todo en la página de precios o echa antes un vistazo a la demo en directo.
Empieza gratis y sube de plan cuando la web importe. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.