¿Cómo te enteras de que tu web está caída antes de que te lo diga un cliente?
En resumen
Que te lo diga un cliente se paga dos veces: pierdes las ventas y das la impresión de no estar mirando. Enterarte tú primero necesita tres cosas: una comprobación que siga lo que hace de verdad un cliente, un aviso que no puedas perderte y bastante contención como para que sigas creyéndotelos dentro de un mes.
Toda caída tiene dos costes. El primero son los pedidos que no llegaste a aceptar. El segundo es la frase “vuestra web lleva caída desde ayer”, escrita por un cliente que se enteró antes que tú, y ese se paga en confianza, durante mucho más tiempo.
¿Por qué se da cuenta el cliente antes que tú?
Porque el cliente está haciendo algo concreto —comprar, entrar en su cuenta, pagar— y tú estás mirando un panel, o no estás mirando nada.
Las historias son siempre parecidas. Un sitio caído durante al menos un día, detectado solo porque un servicio de terceros que no tenía nada que ver acabó mostrando la página por defecto de Apache. Otro, en el que el aviso de la caída se había enviado correctamente y había aterrizado en la carpeta de spam. En los dos casos, lo que falló no fue la monitorización: fue darse cuenta.
¿Basta con la página de inicio?
Es el mínimo, y responde a una pregunta más estrecha de lo que la mayoría cree. Una página de inicio que devuelve 200 demuestra que un servidor web contesta en esa dirección. No demuestra que se pueda entrar en la cuenta, que el carrito añada, que el paso del pago cargue, que el buscador devuelva algo ni que el correo del pedido salga de casa.
Los fallos que hacen daño a una tienda online están casi todos más abajo de la página de inicio. Así que la comprobación tiene que bajar también: una secuencia guardada que abre una página, sigue un enlace, envía un paso y espera un código de estado concreto o una palabra concreta en la pantalla. Si el paso cuatro deja de devolver la página del pago, te enteras antes de que el primer cliente se rinda.
Hay otras dos comprobaciones que pertenecen al mismo grupo, porque fallan según el calendario y no al azar: el certificado TLS, contado en días restantes, y la fecha de caducidad del propio dominio. Un certificado caducado es una caída completa para todos los visitantes, anunciada con semanas de antelación a quien estuviera contando.
¿Qué tiene que pasar entre el fallo y tu teléfono sonando?
Cinco cosas, y son las que deciden si la monitorización es útil o solo ruidosa: el fallo confirmado, la culpa de la red bien atribuida, el aviso entregado donde estás tú, agrupado en lugar de repetido nueve veces, y repetido más tarde si te olvidas.
Tiene que estar confirmado. Una sola comprobación fallida significa muy poco: un momento lento, un paquete perdido, un hipo de red en algún punto entre los dos extremos. Exigir que el fallo se repita, y pedirle a un segundo punto de observación que esté de acuerdo, elimina casi todas las falsas alarmas sin añadir un retraso que importe.
Tiene que saber de quién es la culpa de la red. Si quien ha perdido la conexión es el que vigila y no el vigilado, eso no es una caída tuya y no debe contarse como tal. Esos fallos hay que ponerlos en cuarentena y comunicarlos como un aviso de plataforma, no como nueve incidentes en tu cuenta.
Tiene que llegar donde estás tú. El correo es la constancia, no la alarma; se filtra, se apila y se lee por la mañana. Un mensaje de chat te alcanza durante el día. Una llamada telefónica es lo que quieres para los dos o tres servicios en los que una hora de silencio sale de verdad cara, y debe respetar las horas de descanso, para que las que sí suenan de noche signifiquen algo.
No tiene que repetirse nueve veces. Cuando cae un servidor, se lleva con él todo lo que había encima. Un aviso para una caída, con un único mensaje de recuperación, es la diferencia entre un aviso que lees y un aviso que silencias.
Tiene que volver si te olvidas. Un recordatorio mientras el servicio sigue caído —después de una hora, después de seis, luego a diario— caza el incidente que alguien confirmó a medianoche y se volvió a dormir.
Y los clientes que preguntan igualmente
Mientras lo arreglas, alguien tiene que contestar al teléfono. Una página de estado pública, con un mensaje corto escrito en el idioma del visitante, convierte veinte interrupciones en un enlace, y es además el registro de lo que pasó, que querrás tener más adelante, cuando alguien pregunte cuánto duró.
Qué hacer esta semana
- Haz la lista de lo que hace de verdad un cliente en tu sitio: entrar en su cuenta, buscar, añadir al carrito, pagar. Esas son tus comprobaciones, no la página de inicio.
- Construye una secuencia que recorra el más valioso de esos caminos y que espere una palabra concreta en el último paso.
- Pon los días restantes del certificado y la caducidad del dominio en algún sitio donde los vayas a ver.
- Elige un servicio que justifique una llamada a las tres de la madrugada —uno solo, elegido con honestidad— y mándalo a una llamada.
- Escribe la página de estado antes de necesitarla. Nadie escribe una buena durante una caída.
El objetivo no es un panel perfecto. Es que la próxima vez que algo se rompa, ya lo estés arreglando cuando escriba el primer cliente.
Lo que no podemos decirte
- No podemos ver si la confirmación de un pedido llegó al buzón del cliente: vemos que tu sitio aceptó el pedido, no lo que hizo después el proveedor de correo con el mensaje.
- No podemos completar un pago real para probarlo: una transacción sintética recorre los pasos y se detiene antes de cobrar nada, así que lo que ocurre del lado del banco queda fuera de nuestra vista.
- No podemos ver una cola, una tarea programada ni una importación atascada a menos que algo de tu lado publique un número que podamos leer.
- No podemos decirte por qué se rompió. Te decimos qué falló, cuándo, desde dónde y qué vio la comprobación; la causa sigue siendo cosa tuya, pero partiendo de mejor información.
Las preguntas que se hacen de verdad
¿Con cuánta rapidez me enteraría?
Depende de cada cuánto se comprueba el sitio: desde cada cinco minutos en el plan gratuito hasta cada quince segundos, más una confirmación breve. Un fallo tiene que repetirse en comprobaciones consecutivas y, en los monitores donde así lo pidas, un segundo punto de observación tiene que verlo también antes de despertar a nadie. Un parpadeo nunca se convierte en una llamada.
Mi página de inicio va bien, pero los clientes no pueden pagar. ¿Se detectaría eso?
Solo si algo comprueba el proceso de compra. Una página de inicio que devuelve 200 demuestra que el servidor web contesta, y nada más. La comprobación que lo detecta es una transacción sintética: una secuencia de pasos guardada —abrir el producto, añadirlo al carrito, llegar al paso del pago— en la que cada paso tiene que devolver la página esperada. Recorre el camino que recorre un cliente y se detiene antes de un cobro real.
¿Y si el aviso acaba en spam, como la última vez?
Entonces el aviso no existe. Es la forma más habitual de que una caída dure un día entero: el correo se envió y lo filtraron. Usa más de un canal para lo que importa: correo para dejar constancia, un mensaje de chat que lees de todas formas y una llamada telefónica para el puñado de servicios que justifican despertar a alguien. Un teléfono sonando es el único canal que no depende de que alguien mire.
¿Cómo evito que me despierten para nada?
Haciendo que la plataforma demuestre la caída antes de escalarla: comprobaciones fallidas consecutivas en lugar de una sola, confirmación desde una segunda ubicación y una regla según la cual, cuando lo que se ha roto es nuestra propia red, tu servicio no se marca como caído por ello. Y después agrupa lo que ocurre junto: un servidor que cae se lleva por delante varios monitores, y eso debería ser un aviso, no nueve.
¿Y el certificado y el dominio?
Los dos caducan en una fecha fija, lo que los convierte en las caídas más fáciles del mundo de evitar y en las más vergonzosas de sufrir. Vigila los días que le quedan al certificado y la fecha de caducidad del propio dominio, y trata el aviso como una tarea con fecha, no como una notificación que se descarta.