El cliente ve el sitio funcionando. Nosotros vemos todo lo que pasa detrás para que siga funcionando.
Cuando un sitio funciona, parece simple. Entra el request, sale la respuesta. El cliente no ve el middleware que resuelve el tenant, el connection pool que abre la base de datos correcta, el logger que registra cada operación.
Esa invisibilidad es el objetivo. Pero para mantenerla, alguien tiene que ver todo lo que pasa detrás.
Cada request que llega al API se registra con timestamp, tenant, endpoint, método y duración. No para auditoría — para diagnóstico. Cuando algo falla, el log es la primera fuente de verdad.
Los errores se capturan con stack trace completo y contexto: qué request lo provocó, en qué tenant, en qué momento. Un error sin contexto es un acertijo. Un error con contexto es un problema con solución.
Rate de errores 5xx: si más del 2% de los requests terminan en error de servidor, hay un problema.
Tiempo de respuesta: si el p95 supera los 800ms, algo está lento.
Conexiones de base de datos: si el pool está saturado, las requests empiezan a esperar.
Espacio en disco: si queda menos del 20%, hay que actuar antes de que llegue al límite.
El cliente nunca ve el panel de observabilidad. Pero sí nota su ausencia: en los sistemas que no tienen logs ni alertas, los problemas se detectan cuando el usuario los reporta.
"La página no carga" es una alerta tardía. Para cuando el cliente llama, el problema ya tiene minutos o horas de antigüedad.
La observabilidad correcta detecta el problema antes de que el cliente lo note. Eso transforma la relación de soporte: en lugar de reaccionar a incidentes, prevenimos que sucedan.
No somos perfectos en esto. Hay incidentes que no anticipamos. Pero cada incidente que no anticipamos se convierte en una alerta nueva. El sistema de observabilidad crece con cada cosa que aprendemos.
La capa editorial necesita estructura, no solo publicacion.
Metadata, taxonomias y locale afectan el valor futuro del contenido.