# A página de Runners: gerenciamento da frota

> Gerencie sua frota de runners a partir do dashboard: tipos de runner, configurações, uso e economia, o feed de atividade de autorreparo e a ferramenta de migração em massa.

Source: https://latchkey.dev/pt/documentation/runners-dashboard

## Summary

- A página **Runners** = custo e economia da frota, configurações de runner e o feed de atividade de autorreparo.
- Habilitação/desabilitação e concorrência máxima por configuração, e status de build de imagem para runners personalizados; o autorreparo é controlado em todo o workspace nas Configurações.
- **Migrate Runners** (item da barra lateral ou cartão Runner Types, owners/admins) abre um PR por repositório, até 20 repos monitorados por passagem; apenas as linhas `runs-on` mudam, além dos passos de cache do Latchkey quando adicionados.

Tudo sobre sua frota de runners gerenciados fica na página **Runners** ("Manage your runners and review jobs they've run") na barra lateral do dashboard. É o lar operacional dos recursos descritos no restante desta seção.

## O que há na página

- **Métricas da frota** Custo de runners neste período de cobrança, economia estimada vs hospedados pelo GitHub, e minutos do nível gratuito usados contra sua franquia mensal.
- **Runner Types** Um cartão recolhível cobrindo Preset Runners (os quatro tamanhos com especificações e preços por minuto) e AI Scan Runners, com um atalho Migrate Runners no seu rodapé.
- **Your runners** Toda configuração no seu workspace: nome, status, tamanho, concorrência máxima, estado de autorreparo e ligado/desligado, além de uma ação Copy CI snippet por linha.
- **Atividade de autorreparo** KPIs de reparos (Total Attempts, Heals, Success Rate), gráficos de atividade e de categoria, e o feed Recent Heals.

## Uma revisão semanal de cinco minutos

A página recompensa um breve hábito semanal. Uma passagem sugerida:

**Revisão semanal da frota**
- [ ] Métricas da frota: o custo dos runners está seguindo o esperado para este período de cobrança, e quanto da franquia do nível gratuito ainda resta?
- [ ] Economia estimada vs hospedados pelo GitHub: ainda é o que você espera? É sua evidência contínua de que a migração continua compensando.
- [ ] Your runners: há algo desabilitado que workflows ainda apontam? Jobs direcionados a um rótulo desabilitado ficam na fila em vez de falhar, o que é fácil de não notar.
- [ ] Runners personalizados: há builds de imagem ainda pendentes ou que falharam? A linha da configuração mostra o status do build.
- [ ] Recent Heals: quais categorias dominam esta semana, e algum workflow específico está sendo reparado repetidamente?

## A tabela Your runners

A tabela **Your runners** ("Set up runners for your repos. Adjust size, concurrency, and on/off state.") lista toda configuração no seu workspace: os quatro presets mais quaisquer runners personalizados. As colunas cobrem nome, status, tamanho, concorrência máxima, estado de autorreparo e estado ativo, e o cabeçalho da tabela carrega a ação **AI Scan Runners**; antes do seu primeiro runner ela mostra um estado vazio **Set up your first runner**, e banners de scans pendentes ("Ready for review") aparecem acima dela. Cada linha lhe dá:

- **Habilitar/desabilitar.** Uma configuração desabilitada para de aceitar novos jobs (jobs que apontam para seu rótulo ficarão na fila).
- **Copy CI snippet**, para que ninguém digite um rótulo de memória.
- Uma coluna **Self Healing** mostrando se o reparo cobre o runner; o controle em si é o interruptor de todo o workspace em **Settings, Self-Healing**.
- **Status de build de imagem** para [runners personalizados](/documentation/custom-runners): você pode ver quando uma imagem personalizada ainda está sendo construída versus pronta.
- **Excluir** para configurações personalizadas que você não precisa mais.

Desabilitar e excluir fazem coisas diferentes. Desabilitar é o botão de pausa: o rótulo continua existindo, e jobs que o apontam ficam na fila até você reabilitá-lo, o que o torna a jogada certa enquanto você investiga uma configuração. Excluir é para configurações personalizadas com as quais você terminou de forma permanente.

### O painel de detalhes

Clicar em uma linha abre o painel de detalhes com a configuração completa: rótulo, SO, vCPUs, RAM, disco, imagem base e preço por minuto, além de um cartão **Use in CI** com o rótulo e um snippet copiável do GitHub Actions. Admins podem editar o nome do runner, os rótulos personalizados e **Max Concurrent** (0 = ilimitado); não-admins veem os mesmos detalhes somente para leitura, para que toda a equipe possa ver o que cada runner oferece.

## Recent Heals

A seção de autorreparo ("Recent heal attempts, agent reports, and PR proposals across your org.") lista cada reparo com seu selo de resultado (Healed, No Action, Failed ou Pending) e categoria, abaixo dos KPIs de reparos e dos gráficos **Heal Activity Over Time** e **Heal Rate by Category**. Clicar em uma linha abre o painel **Heal Details** com o relatório completo: o que falhou, o diagnóstico, a ação exata tomada (em linguagem simples) e, para falhas diagnosticadas por IA, as iterações do agente. Execuções reparadas em [Desempenho de pipeline](/documentation/pipeline-performance) têm links diretos para os mesmos relatórios. Se o autorreparo estiver desligado, a seção mostra "Self-Healing is disabled." com um link para habilitá-lo nas Configurações.

Leia o feed como um sinal, não apenas um registro de resgates. Reparos de rede pontuais e dispersos por muitos workflows são o ruído de fundo normal de registries e serviços externos tendo maus momentos. Os padrões são mais interessantes: o mesmo workflow reparado repetidamente na mesma categoria aponta para algo duradouro. Reparos de memória recorrentes sugerem um job que quer um [tamanho de runner maior](/documentation/runners-overview); reparos de disco recorrentes, um job que enche seu disco a cada execução; reparos de ferramenta recorrentes, um passo que assume uma ferramenta que o workflow nunca instala. Esses são exatamente os casos em que uma correção permanente supera ser resgatado toda noite; veja [pull requests de reparo](/documentation/self-healing) para saber como o autorreparo propõe essas correções por conta própria.

## Migrate Runners

A ferramenta tem dois pontos de entrada, e ambos abrem o mesmo modal **Migrate runners**: o item **Migrate Runners** na barra lateral do dashboard e o CTA no rodapé do cartão Runner Types ("Already have workflows on GitHub-hosted runners? Migrate them to Latchkey runners in a few clicks."). Esta seção cobre o modal em si; o guia completo, incluindo o mapeamento exato de rótulos, o conteúdo dos PRs, a verificação e o rollback, é [Migre dos runners hospedados pelo GitHub](/documentation/migrate-from-github-hosted).

Cada pull request reescreve todo rótulo `runs-on` suportado para o tamanho certo do Latchkey (rótulos Ubuntu padrão viram `latchkey-small`) e não toca em mais nada; jobs Windows e macOS, rótulos não reconhecidos e linhas com expressões `${{ }}` são deixados em paz. Uma tabela de mapeamento antes e depois para cada arquivo mostra exatamente o que mudou, então a revisão leva minutos, não dias.

- Depois que os PRs estão abertos, o modal lista cada um com seu número de PR e um link View PR: "Opened N pull requests. Merge each on your schedule."
- Se um repositório já tiver um pull request de migração aberto, o Latchkey o vincula em vez de abrir um duplicado.
- Se não sobrar nada para trocar, o modal mostra um estado **Nothing to migrate**.
- Abrir PRs de migração requer um papel de admin ou owner; nada nos seus repositórios muda até sua equipe fazer merge.

> ****
> Os números de custo da frota nesta página sempre refletem o período de cobrança atual, então eles combinam com o que o modal de cobrança vai cobrar, independentemente do filtro de data usado nas páginas de análise.

### O que há na página Runners?

Custo e economia da frota, suas configurações de runner e o feed de atividade do autorreparo em um só lugar. Cada configuração pode ser ativada ou desativada, receber uma concorrência máxima e mostra o status de build de imagem para runners personalizados.

### Como migro repositórios para runners Latchkey em lote?

Use o Migrate Runners, na barra lateral ou no card Runner Types, disponível para owners e admins. Ele abre um pull request por repositório em até 20 repositórios monitorados por passagem, alterando apenas as linhas `runs-on` e os passos de cache do Latchkey quando adicionados.

### Onde ativo ou desativo o autorreparo?

Em Settings, para todo o workspace, e não por configuração. A página Runners controla ativação e concorrência por configuração; o autorreparo é um único interruptor de workspace, para que seu comportamento não divirja entre tipos de runner.

---

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