La API de métricas de uso de GitHub Copilot ahora detalla cuánto tiempo pasan los pull requests en tres etapas del proceso de revisión. En los informes diarios por repositorio repos-1-day, el nuevo array pull_request_review_times ofrece la mediana y el percentil 90 del tiempo desde que el pull request está listo para revisión hasta la primera revisión, desde la primera hasta la última revisión y desde la última revisión hasta el merge. La ventaja práctica es separar retrasos que antes quedaban ocultos dentro del tiempo total hasta el merge.
Qué cambió en la API
Cada entrada de pull_request_review_times contiene authored_by, reviewed_by, total_merged y seis campos de duración en minutos. En esta primera versión, authored_by y reviewed_by aparecen como human. Los pares de mediana y p90 corresponden a tres etapas:
- median_minutes_ready_to_first_review y p90_minutes_ready_to_first_review: desde que el pull request queda listo para revisión hasta su primera revisión humana.
- median_minutes_first_to_final_review y p90_minutes_first_to_final_review: desde la primera hasta la última revisión humana.
- median_minutes_final_review_to_merge y p90_minutes_final_review_to_merge: desde la última revisión humana hasta el merge.
Las duraciones se atribuyen al día en que se hizo merge del pull request. Los campos ya existentes en pull_requests no cambian.
Qué ayuda a diagnosticar cada etapa
| Etapa | Pregunta operativa | Qué puede indicar un valor alto |
|---|---|---|
| Listo para primera revisión | ¿Cuánto espera el código hasta que alguien empieza a revisarlo? | Cola de revisión, poca disponibilidad de revisores, asignación deficiente de ownership o poca superposición de horarios de trabajo. |
| Primera a última revisión | ¿Cuánto duran la discusión y las iteraciones de revisión? | Múltiples ciclos de ajustes, alcance grande, feedback fragmentado o dependencia de varios revisores. |
| Última revisión a merge | ¿Cuánto permanece sin merge un pull request ya revisado? | Espera de checks, ventanas de despliegue, aprobación externa, política de merge o trabajo operativo pendiente. |
Estas lecturas son hipótesis de diagnóstico, no conclusiones automáticas. La métrica muestra dónde se acumula el tiempo, pero la causa debe investigarse con el contexto del repositorio y del flujo de entrega.
La mediana y el p90 deben leerse juntos
La mediana representa el comportamiento típico y es menos sensible a casos extremos. El percentil 90 muestra la cola de lentitud: aproximadamente el 90% de los casos está en ese valor o por debajo y el resto es más lento. Un repositorio puede tener una mediana saludable y un p90 muy alto, lo que indica que la mayoría de las revisiones fluye bien, pero una parte relevante enfrenta esperas largas.
Por eso, no basta con seguir un único promedio general de tiempo hasta el merge. Para cada una de las tres etapas, conviene observar la mediana y el p90 en paralelo. Una razón derivada entre p90 y mediana también puede ayudar a detectar dispersión, siempre que se trate como un indicador calculado por el equipo y no como un campo oficial de la API. Cuando la mediana sea cero, esa razón no debe utilizarse.
Qué métricas conviene seguir en la práctica
- Latencia típica por etapa: las tres medianas muestran dónde consume más tiempo el flujo normal.
- Cola de lentitud por etapa: los tres valores p90 destacan casos que se alejan del comportamiento típico.
- Volumen elegible: pull_request_review_times[].total_merged indica cuántos pull requests calificaron para este recorte ese día. Los percentiles con volumen muy bajo deben interpretarse con cautela.
- Cobertura del recorte: comparar pull_request_review_times[].total_merged con pull_requests.total_merged ayuda a entender qué proporción del volumen total está representada por los tiempos de revisión humana. Es un indicador derivado, no un campo listo de la API.
- Tendencia temporal: seguir los valores diarios por repositorio ayuda a saber si un cuello de botella es recurrente o puntual. No conviene sumar medianas o percentiles para fabricar un percentil mensual, porque los percentiles no son aditivos.
Límites importantes del nuevo recorte
El bloque considera pull requests abiertos por una persona y revisados por al menos otra persona. Las revisiones realizadas por Copilot code review, otros bots o el propio autor quedan fuera del cálculo de etapas. Un pull request revisado tanto por una persona como por Copilot sigue siendo elegible, pero solo se temporizan las revisiones humanas.
Por eso, pull_request_review_times[].total_merged suele ser menor que pull_requests.total_merged, que también puede incluir pull requests integrados sin revisión. En los días sin pull requests elegibles, el array devuelve [], no cero. Cuando existe una sola revisión, la etapa entre primera y última revisión vale cero.
Tampoco existe un backfill completo. GitHub indica que los datos se construyen hacia adelante desde el lanzamiento y que los pull requests que quedaron listos para revisión antes del 21 de septiembre de 2026 no aparecen en esta sección, aunque todavía puedan contar en pull_requests.total_merged. Por lo tanto, los primeros días pueden tener muestras menores.
Dónde aparecen los datos y quién puede acceder
Los campos están disponibles en los informes diarios de nivel de repositorio repos-1-day, tanto en el ámbito de empresa como de organización. La documentación de la API describe endpoints como GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD, que devuelven enlaces temporales para descargar el informe.
El acceso depende de los permisos de métricas de Copilot. Entre los perfiles citados por GitHub están propietarios de empresa, responsables de facturación empresarial, propietarios de organización y personas con roles personalizados que concedan el permiso correspondiente para ver métricas de Copilot. La política de métricas de uso de Copilot también debe estar habilitada.
Cómo convertir el nuevo bloque en un panel útil
Una implementación sencilla puede guardar, por repositorio y día, los seis valores de latencia y total_merged. El panel puede mostrar tres pares de mediana y p90 con el volumen al lado. Así se evita interpretar un pico de p90 sin saber si representa decenas de pull requests o solo unos pocos casos.
Para análisis operativo, lo más útil es comparar las etapas a lo largo del tiempo. Si el mayor retraso está antes de la primera revisión, la investigación puede empezar por capacidad y asignación de revisores. Si está entre revisiones, el foco puede pasar al tamaño de los cambios, la claridad del feedback y los ciclos de retrabajo. Si está después de la última revisión, conviene revisar checks, políticas y proceso de integración. La API señala dónde aparece el retraso en el ciclo, pero determinar la causa y la corrección sigue dependiendo del contexto del equipo.
