# Desempenho de pipeline

> Durações de build, taxas de sucesso e falha, MTTR, execuções recentes de workflow e onde aparecem as execuções autocorrigidas.

Source: https://latchkey.dev/pt/documentation/pipeline-performance

## Summary

- Saúde de workflows, durações, falhas e métricas de recuperação (MTTR, taxa de sucesso de rebuild) em um só lugar.
- A tabela de execuções (ordenável, 13 por página, mais recentes primeiro) vincula cada execução ao GitHub; execuções corrigidas trazem um selo verde **Healed** que abre o painel Heal Details.
- As tendências capturam a lenta escalada; Top Failed Builds encontra os incêndios ativos.

A página Pipeline Performance acompanha quão saudáveis e quão rápidos são seus workflows.

Há duas formas de usá-la. Como **monitor**, você dá uma olhada na visão geral e nas tendências para responder "a CI está melhorando ou piorando?" Como **ferramenta de investigação**, você filtra até um repositório ou workflow e usa a tabela de execuções e as métricas de recuperação para responder "o que exatamente aconteceu, e como lidamos com isso?" As seções abaixo estão dispostas aproximadamente nessa ordem.

## Performance Overview

- **Workflow Health**: taxa de sucesso geral como um medidor.
- **Average Build Duration**, **Successful Builds** e **Failed Builds** para a janela selecionada.
- **Top Failed Builds**: os três repositórios e os três workflows com mais builds com falha. Cada entrada tem link direto para o repositório ou o arquivo de workflow no GitHub, para que você possa pular do ponto crítico para a correção.
- Contagens de **Repositories Monitored** e **Workflows Monitored**, confirmando exatamente o que os números abrangem.

Orientação para ler o medidor: um único dia ruim raramente significa muito; uma única mesclagem quebrada pode afundar a taxa de sucesso de um dia sozinha. O que merece atenção é uma queda sustentada ao longo da janela, ou uma diferença entre repositórios: se a saúde de um repo fica muito abaixo do restante, **Top Failed Builds** geralmente nomeará o workflow responsável, e seu link direto leva você diretamente ao arquivo de workflow no GitHub.

## Build Trends

- **Successful Builds Over Time by Repository**: a tendência diária de builds bem-sucedidos, uma linha por repositório.
- **Average Build Duration by Repository** e **Workflow Duration**: gráficos de barras classificando repositórios e workflows por duração média, cada um com um menu suspenso **Top 5 / Bottom 5**. Os rótulos dos gráficos têm link para o repositório ou o arquivo de workflow no GitHub.
- **Build Duration Trend Across Workflows** para identificar pipelines que estão ficando mais lentos.

As tendências de duração vêm em dois formatos que vale distinguir. Uma **mudança em degrau** (a duração salta em um dia específico e permanece lá) quase sempre remonta a uma edição concreta: uma nova etapa, uma mudança de dependência, um runner diferente. Uma **lenta escalada** é o problema mais silencioso: conjuntos de testes crescentes e etapas acumuladas que ninguém percebe semana a semana. Os gráficos de tendência existem para tornar a escalada visível. Os detectores noturnos de confiabilidade do Latchkey observam o mesmo histórico de execuções: uma regressão sustentada no tempo de execução aparece como uma descoberta de confiabilidade no [AI Insight](/documentation/optimization-insights), com a evidência a um clique de distância.

## Recent Workflow Runs

A tabela Workflow Runs é um único feed de execuções individuais em todos os seus repositórios: ícone de status, timestamp, repositório, workflow, **branch** e duração. Cada coluna é ordenável, a ordem padrão é mais recente primeiro, e as execuções são paginadas a 13 por página. Clicar em uma linha abre a execução no GitHub.

Quando a autocorreção do Latchkey repara uma execução, a tabela mostra um selo verde **Healed** na coluna Heal. Clique nele para abrir o painel **Heal Details** na página Runners: o que falhou, o diagnóstico e a ação exata tomada em linguagem simples; para falhas diagnosticadas por IA, também inclui as iterações do agente. Isso importa ao ler esta página porque uma execução corrigida conta como um resgate, não uma passagem limpa: se o mesmo workflow continua precisando de correções, a instabilidade subjacente ainda está ali para ser resolvida. Veja [Autocorreção](/documentation/self-healing) para como a correção funciona e [a página Runners](/documentation/runners-dashboard) para o feed completo de Recent Heals.

## Recovery & Comparative Analysis

- **Build Fail Rate** e **Rebuild Success Rate**: com que frequência os builds falham, e com que frequência uma re-execução fica verde.
- **Mean Time to Recovery (MTTR)** e **MTTR Over Time**: o tempo médio entre um build com falha e o próximo build bem-sucedido, acompanhado de sua tendência diária.
- **Build Status by Repository**: builds bem-sucedidos, com falha e cancelados por repositório em um gráfico de barras empilhadas, com um menu suspenso Top 5 / Bottom 5.

### O que cada métrica de recuperação informa

**MTTR** é o tempo médio entre um build com falha e o próximo build bem-sucedido. Ele mede todo o ciclo de recuperação da sua equipe: notar o build vermelho, diagnosticá-lo e entregar a correção. Não há um número "bom" universal; uma equipe que faz deploy muitas vezes ao dia precisa de MTTR medido em minutos, enquanto uma equipe de release semanal pode tolerar horas. O que é universalmente ruim é uma tendência crescente de **MTTR Over Time**: significa que as falhas estão ficando mais difíceis de diagnosticar, ou que a equipe está ficando mais lenta para responder, e qualquer uma das duas se agrava.

**Rebuild Success Rate** é o detector de instabilidade. Ele lhe diz qual fração das falhas desaparece quando você simplesmente executa o build de novo, e os dois extremos apontam para problemas muito diferentes:

**Build Fail Rate** só se torna significativa ao lado da taxa de sucesso de rebuild. Uma taxa de falha de 10% feita de regressões reais e uma taxa de falha de 10% feita de falhas instáveis do tipo re-execute-e-esqueça são problemas inteiramente diferentes, e esta página lhe dá ambos os números precisamente para que você possa distingui-los.

## Glossário de métricas

| Métrica | O que ela mede | Como lê-la |
| --- | --- | --- |
| Workflow Health | Taxa de sucesso geral para a janela selecionada, mostrada como um medidor | Observe movimento sustentado, não quedas de um único dia |
| Average Build Duration | Duração média de execução no escopo selecionado | A tendência importa mais do que o número absoluto |
| Build Fail Rate | Com que frequência os builds falham | Interprete-a junto com a taxa de sucesso de rebuild |
| Rebuild Success Rate | Com que frequência uma re-execução de um build com falha fica verde | Alta = falhas transitórias/instáveis; baixa = regressões reais |
| MTTR | Tempo médio entre um build com falha e o próximo build bem-sucedido | Mede seu ciclo detectar-diagnosticar-corrigir de ponta a ponta |
| MTTR Over Time | MTTR como tendência ao longo da janela | A direção importa mais; uma linha crescente se agrava |

**Uma revisão semanal sugerida (adapte ao seu gosto)**
- [ ] Compare o medidor Workflow Health com a semana passada
- [ ] Examine Top Failed Builds em busca de um workflow reincidente
- [ ] Confira Build Duration Trend Across Workflows para o pipeline que cresce mais rápido
- [ ] Leia a direção de MTTR Over Time
- [ ] Abra o relatório de uma execução corrigida e pergunte se a instabilidade subjacente merece uma correção de verdade

### O que é o selo Healed em uma execução de workflow?

Um selo verde Healed indica que o autorreparo corrigiu algo durante aquela execução. Ao selecioná-lo, abre-se o painel Heal Details, que mostra o que falhou, o que foi aplicado e se o passo passou depois, de modo que um heal é auditável e não algo que aconteceu em silêncio.

### Qual métrica acompanhar para perceber o CI ficando mais lento?

Build Trends, não a duração atual. As tendências capturam a degradação lenta ao longo de semanas, que é como a maioria dos pipelines piora; uma execução lenta isolada é ruído. Use Top Failed Builds para o problema oposto, os incêndios ativos de hoje.

### O que significam MTTR e taxa de sucesso de rebuild aqui?

MTTR é o tempo médio entre uma execução com falha e a próxima bem-sucedida no mesmo workflow, ou seja, mede a recuperação e não a falha. A taxa de sucesso de rebuild é a proporção de reexecuções que passam; uma taxa baixa indica que reexecutar não resolve e a falha é real, não instável.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt