200 OK: qué significa y qué esconde
200 OK significa que el servidor recibió la petición, la entendió y devolvió una respuesta correcta, pero no dice nada sobre si el contenido de esa respuesta es correcto. Un aviso de mantenimiento, una página de error y una plantilla vacía se pueden servir todos con un 200.
Qué garantiza un 200
Un 200 es el estado de éxito estándar. Te dice un conjunto estrecho y específico de cosas: el DNS resolvió, se estableció una conexión TCP, TLS se negoció si la URL era HTTPS, el servidor aceptó la línea de petición y las cabeceras, y produjo una respuesta que considera correcta. Para un GET el cuerpo es el recurso pedido; para un POST es el resultado de la acción.
Lo que un 200 no te dice es si la página contiene el catálogo de productos, si se renderizó el formulario de pago, si el JavaScript que rellena la página recibió sus datos, o si la respuesta que obtuviste es la misma que están recibiendo tus visitantes de otro país. Todo eso vive en el cuerpo, y el código de estado nunca mira el cuerpo.
El 200 que en realidad es un fallo
La monitorización de código de estado por sí sola no es suficiente, porque un sitio roto responde 200 en todos estos casos:
- Una página de mantenimiento. Servida deliberadamente con un 200 por un script de despliegue o una regla de CDN. El uptime parece perfecto durante toda la ventana de la caída.
- Una excepción de aplicación capturada. El framework atrapa el error y renderiza una página amistosa de "algo salió mal" a través del pipeline normal de plantillas, que fija el estado por defecto en 200.
- Un 404 suave. Un mensaje de "página no encontrada" devuelto con 200 en lugar de 404. Los visitantes se confunden y los buscadores pueden seguir teniendo la URL indexada o tratar todo el patrón como de baja calidad.
- Una cáscara vacía renderizada del lado del cliente. El documento HTML carga bien, pero la llamada a la API que lo rellena falló. El estado es 200 y la página está en blanco.
- Una copia en caché obsoleta o en el idioma equivocado. Un nodo de borde cuya obtención del origen falló sigue sirviendo lo que ya tiene, con un 200.
- Un dominio aparcado o secuestrado. Tras un cambio de DNS responde 200 con el contenido de otro.
Un 200 lento sigue siendo un problema
El tiempo de respuesta a menudo importa más que el código. Una página que tarda doce segundos en devolver un 200 está funcionalmente caída para la mayoría de los visitantes, que se habrán ido antes de que termine. El código de estado no tiene ninguna dimensión temporal, así que tienes que medir el tiempo de respuesta y ponerle un umbral por separado. El tamaño también merece vigilarse por el mismo motivo: un 200 que devuelve 300 bytes donde normalmente devuelve 80 KB es una señal fuerte de que la página se renderizó sin su contenido.
Cómo verificar que un 200 es un éxito real
- Lee la línea de estado y el tiempo juntos:
curl -sI -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com/ - Obtén el cuerpo y haz una aserción sobre una cadena que solo aparece cuando la página funciona de verdad, como un encabezado, un precio o una marca de pie de página, en lugar de sobre algo que también contiene la plantilla de error.
- Haz aserciones tanto sobre la ausencia como sobre la presencia. Buscar frases como "en mantenimiento", "temporalmente no disponible" o el texto de excepción de tu framework detecta el caso de la página de error amistosa.
- Compara el tamaño de la respuesta contra una línea base conocida como buena. Un colapso repentino en la longitud del cuerpo normalmente significa que se renderizó la cáscara y no el contenido.
- Comprueba una página profunda, no solo la página de inicio. Las páginas de inicio son las que más se cachean y las que más probablemente sigan respondiendo 200 mientras la aplicación detrás está rota.
- Repite desde más de una red. Un 200 desde tu oficina y un error desde otro continente señala al DNS, la CDN o el enrutamiento geográfico y no a la propia aplicación.
Lo que se le puede escapar a una comprobación de uptime en verde
Un monitor que solo lee el código de estado reportará un sitio en verde durante toda una incidencia que empezó con una página de mantenimiento que nadie quitó. Combinar la comprobación de estado con una aserción de palabra clave y un umbral de tiempo de respuesta es lo que convierte "el servidor respondió" en "la página funcionó". HostTracker ofrece 13 tipos de monitor y avisa por correo, SMS, llamada de voz, Slack, Telegram y más, así que un desajuste de contenido dispara la misma alerta que dispararía una caída. Pasa una URL por la herramienta de comprobación HTTP para ver su estado, sus cabeceras y sus tiempos, o lee sobre la familia 2xx y el 500 Internal Server Error para las respuestas que esconde una página de error amistosa.