Por qué tu alojamiento no te avisa cuando el sitio se cae

Tu servidor no se ha movido. El disco va bien, la red responde, el procesador se aburre. Y tu portada devuelve un error 500 a todos los visitantes desde hace seis horas.

Las dos afirmaciones son ciertas al mismo tiempo, y ahí está todo el malentendido. Tu alojamiento no te miente ni te descuida: mira otra cosa distinta de lo que crees que mira.

Lo que vigila, lo que no ve, quién lo ve

La columna de la derecha es la que cuenta: en cinco casos de ocho, la única persona enterada es un visitante, y un visitante no te escribe. Se va al resultado siguiente, y tú solo sabrás de esa avería si por casualidad miras.

Dos objetos distintos

Un alojamiento vigila la máquina: ¿tiene corriente, es alcanzable, le queda espacio en disco, pasa la red? Su vigilancia existe para cumplir su propio compromiso, que se refiere a la infraestructura.

Tu sitio es una aplicación que se ejecuta en esa máquina. Un error de PHP, una extensión actualizada de través, un certificado caducado, una base de datos parada: nada de eso enferma la máquina. Desde el punto de vista del alojamiento todo es normal, y de hecho tiene razón.

Las cinco averías que un alojamiento nunca señalará

El certificado caducado. El servidor responde perfectamente, es el navegador el que se niega a mostrar. Ningún indicador de infraestructura se mueve, y esa avería no deja rastro en tus registros.

El despliegue fallido. La raíz de documentos apunta al sitio equivocado, una ruta es falsa, falta un archivo de configuración. La máquina sirve concienzudamente una página de error, que es exactamente su trabajo.

El error de la aplicación. Una actualización de extensión, una dependencia incompatible, una base que rechaza las conexiones. El servidor web responde, y responde un 500.

La lentitud. Ocho segundos por página es una respuesta válida para una supervisión de infraestructura. Para un visitante, es un sitio roto.

La caída parcial. La portada va bien, el proceso de compra está muerto. Ninguna herramienta que solo pruebe la raíz del dominio lo verá, incluida la tuya si la has configurado así. Es además la avería más cara, porque toca justamente las páginas donde se gana dinero.

Lo que un alojamiento sinceramente no puede saber

Ni con la mejor voluntad, un proveedor sabe:

• qué se supone que muestra tu portada;
• si una redirección 302 es voluntaria o el resultado de un despliegue fallido;
• si una página en blanco es una decisión de diseño o un error fatal detectado demasiado tarde;
• si tu certificado cubre el subdominio que usan tus clientes;
• si el formulario de contacto todavía envía algo a alguien.

Responder a esas preguntas supone cargar tus páginas y saber qué debería haber en ellas. No es su oficio, y sinceramente, no debería serlo: un alojamiento que inspeccionara el contenido de tus páginas plantearía otros problemas, bastante más incómodos.

Leer una página de estado sin caer en la trampa

Una página de estado en verde no dice «tu sitio funciona». Dice «no hemos declarado ningún incidente en nuestros servicios». Tres matices merecen la pena.

Es declarativa. Un incidente aparece cuando alguien lo escribe, a menudo tras una confirmación interna, a veces con una hora de retraso respecto al momento en que tú lo viste.

Es global. Un incidente que afecta a trescientos servidores de cincuenta mil puede no figurar nunca, lo cual es comprensible y no te consuela si estás entre los trescientos.

No cubre los servicios vecinos. El registrador, el proveedor de correo, la CDN, la pasarela de pago tienen cada uno la suya, y una avería en cualquiera de ellos se lee en tu sitio sin aparecer en ninguna parte en tu alojamiento.

El caso de la administración gestionada

Existen contratos que cubren realmente la aplicación: administración gestionada, soporte gestionado, ofertas con compromiso de disponibilidad aplicativa. Cuestan más, y a veces cumplen su promesa.

Dos comprobaciones antes de contar con ello. Lee qué vigila exactamente el contrato: «supervisión 24/7» designa casi siempre la infraestructura, no tus páginas. Y pregunta qué desencadena una intervención: un umbral de carga no es lo mismo que un código HTTP inesperado en tu portada.

La prueba que lo zanja cabe en una pregunta al soporte: si mi portada devuelve un error 500 durante dos horas un domingo, ¿alguien de ustedes se da cuenta? La respuesta es instructiva, sea cual sea.

Lo que puedes esperar razonablemente de tu alojamiento

El objetivo de este artículo no es hacerle un juicio. Presta un servicio preciso, y conviene saber cuál, aunque solo sea para no pagar dos veces por lo mismo.

Espera de él la disponibilidad de la máquina, una red que responde, copias de seguridad que existen de verdad y se restauran de verdad, una página de estado honesta, y un soporte capaz de decir si el incidente viene de su lado.

No esperes de él el conocimiento de tu aplicación, la comprobación de tus certificados aplicativos, la revisión de tus despliegues, ni una alerta cuando tu contenido cambia de forma.

Una buena manera de resumirlo: tu alojamiento responde de la casa, tú respondes de lo que ocurre dentro. Ambas cosas son necesarias, y confundir los dos perímetros es la causa más frecuente de una caída larga.

La prueba de una tarde

Si no estás seguro de lo que cubre tu instalación actual, haz el experimento en lugar de la teoría. En un entorno de preproducción, provoca a propósito tres averías y mira quién te avisa, y en cuánto tiempo.

Para el servicio de la aplicación: deberías recibir algo. Deja caducar un certificado de prueba: ahí es donde la mayoría de las instalaciones descubre su punto ciego. Y por último, rompe una sola página dejando el resto del sitio en pie: es la avería más frecuente en producción, y la que casi ninguna vigilancia detecta por defecto.

El resultado de ese ejercicio vale más que cualquier promesa comercial, incluida la mía.

El punto ciego, en medio

Entre «la máquina está en pie» y «el sitio funciona» existe un espacio donde vive la mayoría de las averías. No los fallos espectaculares: esos se notan. Los discretos: un error en una página, un certificado que caduca un domingo, un formulario que deja de enviarse tras una actualización.

Nadie vigila ese espacio por defecto. Ni tu alojamiento, cuyo trabajo termina antes. Ni tus visitantes, que se van en lugar de escribir. Y es precisamente ahí donde se juega el coste de una caída, puesto que depende menos de la avería en sí que del tiempo que ha pasado en pantalla.

Mirar desde donde miran tus visitantes

El único punto de vista que corresponde a la realidad es el de fuera: cargar la página como un visitante, leer el código de respuesta, comprobar el certificado, y comparar con lo que debería ocurrir.

Esa es exactamente la diferencia entre la vigilancia de infraestructura y la vigilancia de sitio. Las dos son complementarias, no intercambiables, y solo una de ellas te dirá que tu portada está rota desde esta mañana. Queda por decidir quién la pone en marcha: tu propio script o un servicio externo, y a qué ritmo debe ejecutarse la comprobación.

Esa regla, por lo demás, no se detiene en tu servidor. Los enlaces que otros sitios te han dado desaparecen exactamente igual, sin que nadie te escriba y sin que ningún informe lo muestre: el mismo punto ciego, una capa más allá.

Y el día en que llegue la alerta, no te dirá qué hacer: los primeros quince minutos siguen siendo los mismos, con o sin alojamiento al teléfono.