Um cliente relata que o app está quebrado mas você não consegue reproduzir. O que você olha?

Comece pelos detalhes: qual conta, que horas, qual ação, o que a pessoa viu. Depois siga aquela requisição por logs, traces e relatórios de erro usando um id de requisição ou de trace compartilhado, para você ver o caminho inteiro em vez de um serviço só. Compare taxa de erro e latência com a mesma janela de ontem para separar uma regressão real de ruído de fundo. Se nada aparece, a lacuna é de instrumentação, então adicione logs estruturados naquele caminho.

A primeira coisa que eu faço é transformar o relato em algo pesquisável: id da conta, horário aproximado com fuso, qual botão, o que apareceu na tela. Relatos vagos ficam insolúveis, então essa conversa vale cinco minutos. Depois eu vou no trace de uma requisição naquela janela e sigo entre os serviços, porque uma linha de log de um serviço só raramente te diz se a falha foi nossa, do banco ou de um terceiro. Junto com isso eu olho taxa de erro e latência comparadas ao mesmo horário do dia anterior, já que um pico que começou em um horário de deploy conhecido normalmente é a resposta inteira. Uma coisa que eu aprendi a checar cedo é se aquilo é ambiental: uma região, um navegador, um service worker desatualizado servindo assets antigos, ou um proxy corporativo removendo um header. Se nada é visível em lugar nenhum, eu paro a caçada e trato aquilo como o achado, e então adiciono logs estruturados com o id da requisição, o id do usuário e os ramos de decisão naquele caminho, para o próximo relato levar minutos. Logs ganham identificadores, nunca tokens nem dados pessoais.