Un cliente reporta que la aplicación está rota pero no puedes reproducirlo. ¿Qué miras?

Empieza por lo concreto: qué cuenta, a qué hora, qué acción, qué vieron. Luego sigue esa petición a través de logs, trazas e informes de error con un id de petición o de traza compartido, para ver el camino entero en vez de un solo servicio. Compara la tasa de error y la latencia con la misma ventana de ayer para separar una regresión real del ruido de fondo. Si no aparece nada, el hueco es de instrumentación, así que añade logs estructurados en ese camino.

Lo primero que hago es convertir el reporte en algo buscable: id de cuenta, marca de tiempo aproximada con zona horaria, qué botón, qué apareció en pantalla. Los reportes vagos siguen sin resolverse, así que esa conversación vale cinco minutos. Luego voy a la traza de una petición en esa ventana y la sigo entre servicios, porque una sola línea de log de un servicio rara vez te dice si el fallo fue nuestro, de la base de datos o de un tercero. En paralelo miro la tasa de error y la latencia comparadas con la misma hora del día anterior, ya que un pico que empezó a la hora de un despliegue conocido suele ser toda la respuesta. Algo que he aprendido a comprobar pronto es si es ambiental: una región, un navegador, un service worker obsoleto sirviendo assets viejos, o un proxy corporativo quitando una cabecera. Si no se ve nada en ninguna parte, dejo de cazar y trato eso como el hallazgo, y luego añado logs estructurados con el id de petición, el id de usuario y las ramas de decisión de ese camino para que el siguiente reporte lleve minutos. Los logs llevan identificadores, nunca tokens ni datos personales.