Cuando una pyme me dice “la web no se ha caído nunca”, casi siempre significa otra cosa: que nadie se enteró. Lo habitual no es un 404 gigante. Lo habitual es una caída parcial: el formulario no envía, el checkout devuelve error, la web carga pero sin estilos, o una página clave tarda tanto que la gente se va.
Ya he escrito sobre “aviso de caída de leads”. Esto es distinto: aquí quiero cubrir disponibilidad y funcionamiento de la web y de sus puntos críticos, aunque no se traduzca inmediatamente en “cero leads”. En 60–90 minutos puedes dejar un sistema que te avise en minutos y te ahorre días de pérdida silenciosa.
Paso 1 (10–15 min): elige 5–8 URLs críticas. No monitorices “toda la web”. Monitoriza lo que duele: home, página de contacto, landing top, endpoint del formulario (si existe), página de gracias, login (si aplica) y checkout/reserva (si aplica). Si no sabes cuáles, usa este criterio: páginas por las que entra dinero o solicitudes.
Paso 2 (15–20 min): configura un monitor de uptime. Te vale una herramienta sencilla que haga una petición cada 1–5 minutos y avise si falla. Lo importante no es la marca, es que: (a) puedas añadir varias URLs, (b) te llegue un aviso por email/Slack, y (c) quede un histórico. Trade-off: si monitorizas cada minuto, detectas antes pero puedes tener más “ruido” con microcortes. Para pymes, 3–5 minutos suele ser buen equilibrio.
Paso 3 (20–30 min): crea una “prueba diaria” real. El uptime no detecta que el formulario esté roto si la página carga. Necesitas un test que simule un usuario: enviar un formulario de prueba una vez al día (o cada 6–12 horas) y comprobar que llega al destino correcto (email/CRM). Si tienes e-commerce, haz un “pedido de prueba” con entorno de pago de pruebas o, si no es viable, al menos recorre el proceso hasta el paso anterior al pago. Esto es lo que más valor da porque detecta fallos lógicos, no solo caídas.
Paso 4 (10–15 min): define alertas accionables. Un aviso útil tiene: qué URL falló, desde cuándo, y quién lo atiende. Evita enviar a un buzón que nadie mira. Yo prefiero un canal (Slack/Teams) + una persona responsable. Y un segundo aviso si pasan 30 minutos sin resolver, para evitar que se quede “en visto”.
Paso 5 (10 min): deja un checklist de respuesta. En un documento corto: 1) comprobar si es general o solo tu web (desde 4G, otro navegador), 2) revisar cambios recientes (deploy, plugins, DNS), 3) contactar con proveedor con datos (hora, URL, captura), 4) activar modo mantenimiento si es grave. El objetivo es reducir el tiempo hasta la primera acción.
Errores comunes (y cómo detectarlos): 1) Monitorizar solo la home. Se detecta porque “todo verde” pero el formulario/checkouts están rotos. 2) Alertas a un email genérico. Se detecta porque el aviso se lee tarde. 3) Ruido por falsas alarmas. Se detecta cuando el equipo deja de hacer caso. Solución: sube el umbral (por ejemplo, 2 fallos seguidos) y revisa frecuencia.
Cómo medir resultado: mide el tiempo de detección (de días a minutos) y el tiempo de resolución (con checklist y datos, baja mucho). Si captas leads online, añade una métrica simple: leads perdidos estimados por hora de caída (aunque sea aproximado). Eso te ayuda a priorizar.
Cuándo compensa delegar: si necesitas pruebas automáticas más avanzadas (checkout completo, login, flujos multi-paso) o quieres integrar alertas con n8n/Make para crear tickets, escalar por horario y dejar trazabilidad, delegaría. Ahí ya estás construyendo un “sistema operativo” de la web, y merece hacerlo bien una vez.
