O que realmente há dentro do run_results.json do dbt, e por que vale a pena lê-lo diretamente?

Sem precisar de conta no dbt Cloud, histórico de consultas do warehouse, ou instrumentação extra - target/run_results.json já tem o tempo por modelo de cada execução desde a última vez que você limpou o diretório target.

A forma do arquivo: um objeto de resultado por node

O array results tem uma entrada para cada modelo, teste ou seed que rodou, cada uma com um unique_id, um status («success», «error», «skipped»), um execution_time em segundos, um thread_id, e um array timing que divide esse tempo em fases de compile e execute com timestamps reais.

O thread_id fala sobre concorrência, não só identidade

O dbt roda modelos em paralelo até o número de --threads que você passou. Se seus modelos mais lentos compartilham o mesmo thread_id e rodaram um atrás do outro em vez de sobrepor com outro trabalho, isso é um problema de forma do DAG - uma cadeia de dependências forçando execução serial - não um problema de lentidão por modelo. Vale checar antes de gastar uma tarde otimizando SQL que nunca foi o gargalo.

O que ele não consegue te dizer

Só tempo, não custo. O run_results.json não tem números de bytes escaneados nem créditos consumidos - para custo de computação no Snowflake ou BigQuery você ainda precisa do histórico de consultas do próprio warehouse, cruzado com a execução do dbt via comentário de consulta ou query ID se seu adapter registrar um. Essa é uma lacuna real, não algo para disfarçar.