A API de métricas de uso do GitHub Copilot passou a detalhar quanto tempo pull requests ficam em três etapas do processo de revisão. Nos relatórios diários por repositório repos-1-day, o novo array pull_request_review_times informa mediana e percentil 90 para o intervalo entre ficar pronto para revisão e receber a primeira revisão, entre a primeira e a última revisão e entre a última revisão e o merge. O ganho prático é separar atrasos que antes ficavam escondidos dentro do tempo total de merge.
O que mudou na API
Cada entrada de pull_request_review_times traz authored_by, reviewed_by, total_merged e seis campos de duração em minutos. Nesta primeira versão, authored_by e reviewed_by aparecem como human. Os pares de mediana e p90 correspondem a três etapas:
- median_minutes_ready_to_first_review e p90_minutes_ready_to_first_review: do momento em que o pull request fica pronto para revisão até a primeira revisão humana.
- median_minutes_first_to_final_review e p90_minutes_first_to_final_review: da primeira até a última revisão humana.
- median_minutes_final_review_to_merge e p90_minutes_final_review_to_merge: da última revisão humana até o merge.
As durações são atribuídas ao dia em que o pull request foi mesclado. Os campos já existentes em pull_requests continuam inalterados.
O que cada etapa ajuda a diagnosticar
| Etapa | Pergunta operacional | O que um valor alto pode indicar |
|---|---|---|
| Pronto para primeira revisão | Quanto tempo o código espera até alguém começar a revisar? | Fila de revisão, baixa disponibilidade de revisores, distribuição inadequada de ownership ou horários de trabalho pouco sobrepostos. |
| Primeira para última revisão | Quanto tempo a discussão e as iterações de revisão levam? | Múltiplos ciclos de ajustes, escopo grande, feedback fragmentado ou dependência de vários revisores. |
| Última revisão para merge | Quanto tempo um pull request já revisado permanece sem merge? | Espera por checks, janela de deploy, aprovação externa, política de merge ou trabalho operacional pendente. |
Essas leituras são hipóteses de diagnóstico, não conclusões automáticas. A métrica mostra onde o tempo se acumula, mas a causa precisa ser investigada com o contexto do repositório e do fluxo de entrega.
Mediana e p90 devem ser lidos juntos
A mediana representa o comportamento típico e é menos sensível a casos extremos. O percentil 90 mostra a cauda de lentidão: aproximadamente 90% dos casos ficam até aquele valor e os demais são mais lentos. Um repositório pode ter mediana saudável e p90 muito elevado, indicando que a maior parte das revisões flui bem, mas uma parcela relevante enfrenta esperas longas.
Por isso, não basta acompanhar apenas uma média geral de tempo de merge. Para cada uma das três etapas, vale observar a evolução da mediana e do p90 lado a lado. Uma razão derivada entre p90 e mediana também pode ajudar a enxergar dispersão, desde que seja tratada como indicador calculado pela equipe, e não como um campo oficial da API. Quando a mediana for zero, essa razão não deve ser usada.
Quais métricas acompanhar na prática
- Latência típica por etapa: as três medianas mostram onde o fluxo comum consome mais tempo.
- Cauda de lentidão por etapa: os três valores p90 destacam casos que escapam do comportamento típico.
- Volume elegível: pull_request_review_times[].total_merged informa quantos pull requests qualificaram para esse recorte no dia. Percentis com volume muito baixo devem ser interpretados com cautela.
- Cobertura do recorte: comparar pull_request_review_times[].total_merged com pull_requests.total_merged ajuda a entender quanto do volume total está representado nas métricas de revisão humana. Essa comparação é um indicador derivado, não um campo pronto.
- Tendência temporal: acompanhar os valores diários por repositório permite verificar se um gargalo é recorrente ou pontual. Não é recomendável somar medianas ou percentis para criar um percentil mensal, porque percentis não são aditivos.
Limites importantes do novo recorte
O bloco considera pull requests abertos por uma pessoa e revisados por pelo menos outra pessoa. Revisões feitas pelo Copilot code review, por outros bots ou pelo próprio autor não entram no cálculo das etapas. Um pull request que recebeu revisão humana e também revisão do Copilot continua elegível, mas apenas as revisões humanas são temporizadas.
Por isso, pull_request_review_times[].total_merged tende a ser menor que pull_requests.total_merged, que também pode incluir pull requests mesclados sem revisão. Em dias sem pull requests elegíveis, o array retorna [], e não zero. Quando existe apenas uma revisão, a etapa entre primeira e última revisão vale zero.
Também não há backfill completo. Segundo o GitHub, os dados passam a ser construídos a partir do lançamento e pull requests que ficaram prontos para revisão antes de 21 de setembro de 2026 não entram nessa seção, embora ainda possam contar em pull_requests.total_merged. Os primeiros dias, portanto, podem ter amostras menores.
Onde os dados aparecem e quem pode acessar
Os campos estão disponíveis nos relatórios diários de nível de repositório repos-1-day, tanto no escopo de empresa quanto no de organização. A documentação da API descreve endpoints como GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD, que retornam links temporários para download do relatório.
O acesso depende das permissões de métricas do Copilot. Entre os perfis citados pelo GitHub estão proprietários de empresa, gerentes de cobrança empresarial, proprietários de organização e pessoas com função personalizada que conceda a permissão de visualização de métricas do Copilot. A política de métricas de uso do Copilot também precisa estar habilitada.
Como transformar o novo bloco em um painel útil
Uma implementação simples pode registrar, por repositório e dia, os seis valores de latência e total_merged. O painel pode mostrar três pares de mediana e p90, mantendo o volume ao lado. Isso evita interpretar um pico de p90 sem saber se ele representa dezenas de pull requests ou apenas poucos casos.
Para análise operacional, o ponto mais útil é comparar as etapas entre si ao longo do tempo. Se o maior atraso estiver antes da primeira revisão, a investigação deve começar na capacidade e no roteamento de revisores. Se estiver entre revisões, o foco pode ir para tamanho de mudanças, clareza de feedback e ciclos de retrabalho. Se estiver depois da última revisão, vale examinar checks, políticas e processo de integração. A API fornece o local do atraso no ciclo, mas a decisão sobre causa e correção continua dependendo do contexto da equipe.
