El sitio de un cliente está caído: qué hacer en los primeros 15 minutos
Las guías sobre "web caída qué hacer" están casi todas escritas para quien tiene un solo sitio: el suyo. Si en cambio gestionas los sitios de otros, el problema cambia de forma. La parte técnica es la misma — hosting, DNS, aplicación — pero hay una segunda que nadie explica y que pesa más en la relación con el cliente: qué le dices, cuándo se lo dices y qué pasa si no se lo dices en absoluto.
A continuación tienes una checklist para los primeros quince minutos, dividida en bloques de tiempo y pensada para seguirla mientras el sitio está caído.
El primer problema no es técnico: es el retraso de partida
Antes incluso del diagnóstico, hay una pregunta incómoda: ¿cuántos minutos pasan hoy entre el momento en que el sitio se cae y el momento en que te enteras?
Si la respuesta depende de que alguien en la agencia abra ese sitio por casualidad, o de que el cliente se dé cuenta y escriba, el retraso de partida no se mide en minutos — se mide en horas, y en los fines de semana es sistemáticamente peor. Conviene tenerlo presente durante el resto del artículo: los quince minutos que cuentan no son los primeros quince desde que lo sabes, son los primeros quince desde que ocurrió.
[0-2 min] ¿Está caído para todos o solo para ti?
El primer paso no es entender por qué está caído. Es entender si está caído de verdad.
- Ábrelo desde una conexión distinta de la red de tu oficina: el punto de acceso del móvil, datos móviles, una ventana de incógnito.
- Usa un servicio externo de verificación (el clásico "down-for-everyone-or-just-me" o equivalentes): sirve para descartar que el problema sea tu DNS local, tu caché o tu proveedor.
- Mira el código de estado, no solo la página en blanco: un 500 es un problema de aplicación, un timeout sin respuesta suele ser red, servidor apagado o DNS.
Esta fase existe por un único motivo: evitar alarmar a un cliente por un problema que solo tiene tu oficina. Es el error más embarazoso posible, y ocurre más a menudo de lo que se admite.
[2-5 min] Aislar: ¿hosting, DNS o aplicación?
Tres comprobaciones rápidas acotan el problema casi siempre:
¿El dominio resuelve? Si la resolución DNS falla, el problema no es el sitio: es el DNS o — en el peor de los casos — el registro del dominio caducado.
¿El servidor responde? Si el dominio resuelve pero la conexión da timeout, el nivel es de infraestructura: servidor apagado, firewall, hosting con una incidencia. La página de estado del proveedor de hosting es el primer sitio donde mirar, antes incluso de abrir un ticket.
¿El sitio responde, pero mal? Errores 500, página en blanco, "error al conectar con la base de datos": aquí el nivel es de aplicación — una actualización de plugin que salió mal, el espacio en disco agotado, un límite de conexiones alcanzado.
Hay un caso aparte que se reconoce enseguida: si el navegador muestra "tu conexión no es privada", el sitio no está caído, lo que ha caducado es el certificado SSL. Técnicamente es un incidente menor, pero a ojos de los visitantes es el peor de todos, porque habla de seguridad.
[5-10 min] La primera acción de mitigación
No hace falta la solución definitiva. Hace falta lo más rápido que reduzca el daño mientras trabajas:
- Si el hosting tiene una incidencia general, no hay nada que reparar: abre el ticket, apunta el número y pasa directamente a la comunicación. Tu trabajo aquí es informar, no resolver.
- Si es de aplicación y sabes qué ha cambiado hace poco (una actualización, un despliegue, un plugin nuevo), el rollback casi siempre es más rápido que el diagnóstico.
- Si tienes una copia de seguridad reciente y el sitio no se puede recuperar deprisa, restaurar es legítimo incluso antes de haber entendido la causa: entenderla después, con el sitio en pie, le cuesta menos a todo el mundo.
Ponle un límite de tiempo a esta fase. Si a los diez minutos no tienes ni causa ni mitigación, el paso siguiente hay que darlo igualmente — aquí es donde se equivocan la mayoría de las agencias, porque siguen trabajando en silencio con la esperanza de resolverlo antes de tener que escribir.
[10-15 min] El mensaje al cliente
Antes del minuto quince el cliente tiene que haber recibido algo de ti. No la solución: la noticia de que ya estás en ello.
Un mensaje que funciona contiene cuatro cosas y nada más:
Hola [nombre], el sitio [nombre del sitio] no está accesible desde hace aproximadamente [hora]. Nos hemos dado cuenta a las [hora] y ya estamos trabajando en ello: de momento parece un problema [del hosting / del certificado / de la aplicación]. Te pongo al día a más tardar a las [hora + 60 minutos], aunque todavía no esté resuelto.
Qué hay dentro: desde cuándo, cómo te has enterado, qué estás haciendo, cuándo volverás a escribir. Qué no hay: disculpas largas, jerga técnica y, sobre todo, ninguna promesa de hora de resolución. "Te pongo al día a más tardar a las 15:30" depende solo de ti y es fácil de cumplir; "lo resolvemos a más tardar a las 15:30" depende de un hosting que no controlas.
Y luego la parte que casi todo el mundo se salta: el mensaje de cierre. Cuando esté resuelto, escríbelo, con la duración y una línea sobre lo que ha pasado. Un incidente bien comunicado y bien cerrado puede dejar al cliente más tranquilo que antes, porque por una vez ha visto el trabajo que normalmente es invisible.
Los errores que cuestan más que la caída
Esperar a tener la solución antes de avisar. Es el instinto natural — nadie quiere escribir "todavía no sé por qué" — y es el peor error: si entretanto el cliente se da cuenta por su cuenta, la conversación empieza con "¿desde cuándo lo sabíais?".
Avisar sin una estimación de tiempo. "Hay un problema, estamos trabajando en ello" deja al cliente en una espera indefinida, y quien espera de forma indefinida vuelve a llamar. Una estimación, aunque sea solo del próximo aviso, cierra la pregunta.
No cerrar el círculo. Si el último mensaje que ha recibido el cliente es "estamos trabajando en ello", en su memoria el incidente no ha terminado nunca — aunque el sitio volviera a estar en pie veinte minutos después.
La página de estado hace el trabajo que no escala
Con un cliente, la comunicación manual funciona perfectamente. Con quince clientes en el mismo hosting que se cae a la vez, quince mensajes personalizados son una hora de trabajo justo cuando deberías estar resolviendo.
Una página de estado pública quita de en medio la parte repetitiva: quien se pregunta "¿está caído solo para mí?" abre una página y ve el estado actual, la hora de la última comprobación y las incidencias recientes, sin llamar a nadie. No sustituye al mensaje — ese sigue siendo tu trabajo, y es la parte que el cliente recuerda — pero elimina las peticiones de confirmación, que durante un incidente son la mayoría. Y fuera de los incidentes hace un segundo trabajo: es la prueba continua de que alguien está vigilando, incluso en los meses en que no pasa nada.
El coste de enterarte por el cliente en lugar de por una alerta
Una caída de una hora descubierta en dos minutos y una caída de una hora descubierta al día siguiente no son el mismo incidente: en el segundo caso la hora se ha convertido en un día. Es la cuenta que hicimos con detalle en el artículo sobre cuánto cuesta una hora de e-commerce caído — el resumen es que, para una tienda pequeña, el coste de una sola hora es modesto, mientras que el coste de las horas en que nadie se dio cuenta de nada no lo es en absoluto.
Luego está el coste que no entra en ninguna hoja de cálculo: la posición desde la que hablas. Un cliente al que avisas tú tiene delante a una agencia que está trabajando; un cliente que avisa él tiene delante a una agencia despistada, aunque lo hayas resuelto en diez minutos.
Cómo se comprime el minuto cero
De la checklist anterior, la fase [0-2 min] es la única totalmente automatizable — y es también la que, hecha a mano, exige la condición más improbable de todas: que alguien esté mirando ese sitio exactamente cuando se cae.
Ahí es donde interviene Statuo: los sitios se comprueban de forma continua desde varias ubicaciones independientes y una incidencia solo se declara cuando al menos dos ubicaciones la confirman. Cuando llega el aviso — por email o Telegram — la pregunta "¿está caído para todos o solo para mí?" ya tiene respuesta, y una única comprobación fallida desde un punto de la red nunca genera una falsa alarma que tengas que trasladar al cliente. El diagnóstico y la reparación siguen siendo cosa tuya: lo que cambia es que los quince minutos empiezan de inmediato, no desde que alguien se da cuenta.
Junto con el aviso viene la página de estado con la marca de tu agencia, ya en línea, que los clientes consultan durante el incidente. La prueba gratuita dura 14 días, sin tarjeta de crédito: el tiempo de activarla en los sitios que gestionas y ver de dónde llega el primer aviso.