Hace poco salió en Hipertextual una noticia sobre una caída de Cloudflare que afectó a muchísimos sitios durante horas. No voy a entrar en el “qué pasó” porque, sin datos internos, sería especulación. Lo que sí sé (por experiencia) es lo que pasa en una pyme cuando un proveedor externo falla: WhatsApps, correos, tickets, gente del equipo tocando cosas sin coordinación y, lo peor, leads que se pierden en silencio.
Mi enfoque en estos casos es simple: no intento “evitar” una caída global (no está en tu mano). Intento que, cuando ocurra, tu negocio tenga un sitio donde comunicar y un comportamiento predecible. Con 60–90 minutos puedes montar un plan anti-caídas que reduce mucho el daño.
Paso 1 (15–25 min): crea una status page. Puede ser una página sencilla fuera de tu infraestructura habitual (en un servicio de páginas estáticas o incluso en un subdominio separado). El objetivo es que, si tu web principal está caída, tengas un lugar estable para decir “lo sabemos, estamos en ello” y dejar un canal de contacto. Esa página debe tener: estado actual, última actualización (hora) y qué alternativas hay (teléfono, email, WhatsApp, enlace a compra si aplica).
Paso 2 (20–30 min): prepara un modo mantenimiento “decente”. No me refiero al típico “volveremos pronto” sin más. La página debe: explicar el problema en una frase, dar un tiempo estimado si lo tienes (si no, dilo), ofrecer un formulario simple o un email para captar el lead y, si vendes online, un plan B (por ejemplo, pedido por email/WhatsApp). En Laravel/Django esto suele ser una ruta o plantilla lista para activar; si usas un CMS, normalmente hay plugins o un toggle.
Paso 3 (15–20 min): define quién decide y qué se toca. En un incidente, el mayor acelerador de desastre es que 3 personas cambien cosas a la vez. Dejo escrito (en una nota interna) un protocolo mínimo: una persona “coordina” (decide cuándo activar mantenimiento, cuándo comunicar), otra “ejecuta” (cambios técnicos) y otra “atiende” (clientes/ventas). Aunque seáis dos, se pueden llevar dos sombreros, pero el orden ayuda muchísimo.
Paso 4 (10–15 min): automatiza la comunicación. Si ya usas Slack, crea un canal tipo #incidencias y un mensaje plantilla: “Impacto / servicios afectados / acciones / próxima actualización”. Si no usas Slack, vale con un documento compartido y un grupo. La clave es la cadencia: actualizar cada 30–60 minutos reduce la ansiedad del cliente y baja tickets.
Errores comunes (y cómo detectarlos): 1) La status page depende del mismo proveedor (mismo hosting/DNS/CDN). Lo detectas porque, cuando haces una simulación (apagando acceso o cambiando hosts), también “desaparece”. 2) Modo mantenimiento sin captura de leads. Lo detectas revisando Analytics/CRM: picos de tráfico con cero formularios. 3) Sin responsable claro. Lo detectas cuando hay mensajes contradictorios (“está arreglado” vs “sigue caído”) o cuando nadie sabe quién actualiza el estado.
Cómo medir si te ha servido: dos métricas sencillas. (1) Tiempo hasta la primera comunicación pública (objetivo: <15 minutos). (2) Número de tickets/WhatsApps por hora durante el incidente (debería bajar si la status page y el mensaje están claros). Si tienes e-commerce, añade una tercera: leads capturados durante el incidente (aunque sean menos, que no sea cero).
Cuándo compensa delegar: si tu web factura a diario o depende de campañas, y una hora de caída te cuesta más de lo que vale un día de trabajo técnico, merece la pena montar esto con alguien que lo deje bien atado (dominios separados, activación segura, monitorización y plantillas). Si cada incidente se convierte en “a ver quién arregla esto”, estás pagando el coste en estrés y en pérdida de ventas.
