Sem consolidação manual
Ninguém copia contagem de deploy pra planilha toda sexta. Os números atualizam sozinhos conforme suas ferramentas sincronizam.
← Funcionalidades
FUNCIONALIDADE
DORA Metrics
As quatro métricas que dizem se a engenharia tá mesmo melhorando — frequência de deploy, lead time, tempo de restauro, change failure rate. Calculado, não estimado.
Novo em métricas DORA? Leia nosso guia em bom português do que são e como calcular.
O que faz
O moasy.tech recalcula as quatro métricas DORA automaticamente a partir do que já sincroniza do GitHub, GitHub Actions, ArgoCD, Vercel, Azure Pipelines, Waroom e incident.io — frequência de deploy, lead time de mudança, tempo médio de restauro e change failure rate. Filtra por período ou por time, e todo número vem com uma linha de tendência, pra você ver a direção, não só o retrato de agora.
Dado ilustrativo, apenas para demonstração.
Como funciona
-
Sincroniza
GitHub, GitHub Actions, ArgoCD, Vercel, Azure Pipelines, Waroom e incident.io sincronizam de forma incremental — disparado manualmente ou uma vez por dia sozinhos.
-
Define um deploy
O que conta como deploy de produção, e qual evento inicia a contagem do lead time, é configurável por time — com um padrão da empresa como fallback. Sem CI/CD? Conte transição de board.
-
Correlaciona incidentes
Um deploy só conta como falha quando um incidente de verdade — classificado pelas suas próprias regras — acontece dentro de uma janela configurável depois dele, não por palpite a partir de label de ticket.
-
Calcula & mostra a tendência
As quatro métricas recalculam a partir disso, por time ou pra empresa inteira, com linha de tendência semana a semana — não só o retrato de hoje.
Por que importa
Configurável, não fixo
O que conta como deploy de produção, ou qual evento inicia a contagem do lead time, é configurável por time — com um padrão da empresa como fallback. Times sem pipeline de CI/CD podem contar transição de board em vez disso.
Correlação deploy-incidente, explícita
Change failure rate não é um palpite — um deploy conta como falha quando um incidente de verdade, classificado pelas suas próprias regras, acontece dentro de uma janela configurável depois dele. Dá pra ver exatamente qual config gerou o número.
Por time ou pra empresa inteira
Olhe a empresa inteira, ou filtre por um time só — as mesmas quatro métricas, do jeito que fizer sentido.
Sem deploy contado duas vezes
Conectou mais de uma ferramenta de CI/CD no mesmo time — GitHub Actions e Vercel, por exemplo? O moasy.tech detecta sozinho o risco de contar o mesmo deploy duas vezes, em vez de mostrar um número inflado silenciosamente.
Uma queda sempre tem um marcador por perto
Eventos manuais que você mesmo registra — uma migração, uma saída, um congelamento de deploy — aparecem direto no gráfico de tendência, ao lado de toda mudança de config que também poderia explicar uma variação no número. Veja o quadro completo na feature Timeline.
Clique em qualquer número pra ver o que tá por trás
Todo card de DORA no dashboard é clicável — abre uma tela de detalhe com os deploys, PRs ou incidentes individuais que compõem aquele número, não só o agregado.
Veja essas quatro métricas calculadas a partir do seu próprio dado, não de uma demo.
Começar grátisPerguntas sobre DORA Metrics
O dado de Azure Pipelines ou ArgoCD é tão confiável quanto GitHub Actions ou Vercel?
GitHub Actions e Vercel usam APIs REST oficiais e documentadas. ArgoCD e as integrações do Azure DevOps (Pipelines, Boards, Repos) existem e sincronizam, mas ainda não têm teste ao vivo contra uma conta real — trate números iniciais delas com um pouco mais de cautela até confirmarmos o mesmo histórico.
E se nosso time não tem pipeline de CI/CD?
Você pode contar transição de board em vez disso — mover um ticket pra "Concluído", por exemplo — como o sinal de deploy. As mesmas quatro métricas, um evento de origem diferente.
Como o change failure rate é diferente de só contar ticket de bug?
Ele é atrelado a deploy, não a ticket. Um deploy só conta como falha quando um incidente de verdade — classificado pelas suas próprias regras — acontece dentro de uma janela configurável depois dele. Nem todo ticket de bug é um incidente de produção, e nem todo incidente vem de um deploy.
Dá pra usar incident.io em vez de Waroom?
Dá pra conectar — mesmo pipeline de incidente por trás do MTTR e do change failure rate. Mas o incident.io ainda não resolve um incidente pra um time específico do jeito que o Waroom resolve, e o change failure rate só conta um incidente vinculado a um time — então até isso ser resolvido, o dado do incident.io sincroniza mas ainda não entra nos seus números de DORA. O Waroom continua sendo a escolha confiável pra isso hoje.
Veja seus próprios números DORA
Começar grátis