Preço do GitHub Actions: estime a conta antes da fatura

Dia 5, o financeiro manda print da fatura do cartão corporativo: a linha do GitHub dobrou. Ninguém mudou nada de propósito. O monorepo ganhou testes em três sistemas operacionais, a matriz cresceu e cada push em pull request dispara tudo. A resposta curta: CI tem preço, o preço muda, e alguém precisa ser dono desse número. Confira a tabela atual de preços do GitHub Actions, estime os minutos do mês com uma conta simples, configure orçamento e alerta e corte execução que não precisa acontecer.

Este guia é sobre a conta: como ler um aviso de mudança de preço, estimar o gasto e colocar limite. Se o seu problema é técnico, de workflow lento ou repetido, o passo a passo está no post sobre GitHub Actions gastando minuto demais.

O exemplo deste guia é uma organização fictícia, a loja-acme, no plano GitHub Team, com um repositório privado de API e um de front, e uma equipe de oito pessoas abrindo pull requests o dia inteiro.

Por que a conta do GitHub Actions surpreende

Segundo a documentação de billing do GitHub Actions, o uso é gratuito em repositórios públicos com runners padrão e em runners self-hosted. Em repositórios privados, cada conta recebe uma cota mensal de minutos conforme o plano (em 24/10/2026: 2.000 no Free, 3.000 no Pro e no Team, 50.000 no Enterprise Cloud), e o que passar disso é cobrado do dono do repositório, não de quem disparou o workflow. Isso cria uma sensação de "CI é de graça" que vale até o primeiro repositório privado crescer.

O consumo também não é linear. Minutos de runners Windows e macOS custam mais que Linux, e runners maiores custam mais que os padrão (e nunca usam a cota incluída). O GitHub arredonda cada job para o minuto inteiro de cima, então um job de 10 segundos conta como 1 minuto. Uma matriz de três sistemas operacionais e duas versões de linguagem transforma um job em seis, e se dois deles rodam em macOS, o custo do conjunto sobe bem mais que a contagem de jobs sugere.

Os preços mudam, e o aviso também

Em 16/12/2025, o GitHub anunciou no changelog uma redução de até 39% no preço dos runners hospedados a partir de 1º/01/2026 e uma nova cobrança de US$ 0,002 por minuto para runners self-hosted a partir de março de 2026. Dias depois, o próprio aviso foi atualizado: a cobrança dos runners self-hosted foi adiada para reavaliação, e só a redução dos hospedados seguiu. A documentação de billing consultada em 24/10/2026 continua dizendo que o uso de runners self-hosted é gratuito.

Esse é o motivo de não estimar a conta pela manchete: avisos de preço podem mudar depois de publicados. O que vale é a versão atual da tabela de preços dos runners. Quem não acompanha descobre na fatura.

Como estimar os minutos do mês

A conta é simples e você só precisa de três números: quantas execuções por mês, quantos jobs por execução e quanto dura cada job. Na loja-acme, o workflow de testes da API tem esta matriz:

Jobs por execução: 3 sistemas × 2 versões = 6 jobs
  - 2 em ubuntu-latest   × 6 min
  - 2 em windows-latest  × 9 min
  - 2 em macos-latest    × 8 min

Execuções por mês:
  8 pessoas × 3 PRs/semana × 4 pushes/PR × 4 semanas ≈ 384
  + pushes na main ≈ 60
  Total ≈ 444 execuções

Minutos por sistema no mês:
  Linux   444 × 2 × 6 = 5.328 min
  Windows 444 × 2 × 9 = 7.992 min
  macOS   444 × 2 × 8 = 7.104 min

Com esses minutos, multiplique cada linha pelo preço por minuto do runner correspondente. Com a tabela oficial consultada em 24/10/2026 (runners padrão: Linux 2-core US$ 0,006, Windows 2-core US$ 0,010 e macOS US$ 0,062 por minuto), o exemplo fica assim, antes de descontar a cota do plano:

Linux   5.328 min × US$ 0,006 ≈ US$  31,97
Windows 7.992 min × US$ 0,010 ≈ US$  79,92
macOS   7.104 min × US$ 0,062 ≈ US$ 440,45
Total bruto                    ≈ US$ 552,34

O resultado mostra onde está o dinheiro: o macOS tem menos minutos que o Windows, mas responde por quase 80% da conta. Os minutos incluídos no plano abatem parte disso, conforme a regra da documentação. Refaça a conta com a tabela do dia em que você ler este texto, porque os valores podem mudar.

Para conferir a estimativa com a realidade, use o relatório de uso nas configurações de billing da organização. Ele mostra o consumo por repositório e por tipo de runner.

Como colocar dono, orçamento e alerta

1. Defina quem paga e quem é avisado: a conta de cobrança da organização tem um responsável nomeado, não "o cartão do sócio".
2. Configure orçamento e alertas: nas configurações de billing, crie um orçamento para Actions e ative os alertas por e-mail. Segundo a documentação de orçamentos, com a opção de parar o uso ao atingir o limite marcada, os runners hospedados ficam bloqueados até o próximo ciclo ou até alguém aumentar o orçamento. Escolha conscientemente entre só avisar e bloquear.
3. Acompanhe o changelog: alguém da equipe segue o changelog do GitHub filtrado por Actions e leva qualquer aviso de preço para a reunião da semana.
4. Revise o uso todo mês: compare o relatório de uso com a estimativa. Desvio grande tem causa, e a causa costuma ser um workflow novo.

Como cortar execução que não precisa existir

A otimização técnica de workflows está detalhada no guia sobre minutos do GitHub Actions. Aqui ficam os três ajustes que mais mexeram na conta da loja-acme:

name: testes-api

on:
  pull_request:
    paths-ignore:
      - "docs/**"
      - "**/*.md"
  push:
    branches: [main]

concurrency:
  group: testes-${{ github.ref }}
  cancel-in-progress: true

jobs:
  testes:
    runs-on: ${{ matrix.os }}
    timeout-minutes: 20
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node: [22, 24]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

O paths-ignore evita rodar a suíte inteira por correção de documentação. O concurrency com cancel-in-progress cancela a execução anterior do mesmo branch quando chega um push novo, o que no exemplo eliminou boa parte das 384 execuções de PR. O timeout-minutes impede que um teste travado consuma horas. Um passo além é rodar a matriz completa só na main e, no pull request, apenas Linux. Na conta acima, isso tiraria do PR justamente os minutos de macOS.

Teste instável que obriga a rodar tudo de novo também vira minuto pago. Veja por que rerodar teste flaky piora o CI.

E se a saída for runner próprio?

Quando a conta aperta, alguém sugere rodar runners self-hosted numa máquina da empresa. Pode valer, mas faça a conta inteira: máquina, energia, atualização do sistema, isolamento entre jobs e a pessoa que cuida disso quando o runner cai às 23h. Hoje o GitHub não cobra pelo minuto de runner próprio, mas essa cobrança já foi anunciada uma vez e adiada, então confira a documentação antes de decidir. Runner próprio em repositório público ainda tem risco de segurança: código de pull request de terceiros roda na sua máquina. Explicamos isso em runner self-hosted no notebook.

Erros comuns

• Ignorar aviso de mudança de preço porque o pipeline está verde: verde não é barato, e a diferença aparece direto na fatura.
• Nenhum orçamento configurado: um workflow em loop ou uma matriz exagerada consome o mês inteiro sem ninguém ser avisado.
• Matriz completa em todo pull request: correção de vírgula roda em macOS e Windows, pagando o runner mais caro sem ganho.
• Sem timeout-minutes: um job travado pode rodar até o limite padrão de 360 minutos.
• Cobrança no cartão pessoal de alguém: quando a pessoa sai ou o cartão vence, o CI para ou a conta vira briga.
• Estimar com preço de post antigo: a tabela mudou e o orçamento já nasce errado.

Checklist

• A organização tem um responsável nomeado pela cobrança do GitHub.
• Existe orçamento para Actions com alertas por e-mail configurados.
• Você sabe se o orçamento só avisa ou interrompe o uso.
• Há uma estimativa de minutos por mês, por tipo de runner, com preço da tabela atual.
• Alguém acompanha o changelog do GitHub para avisos de Actions.
• Os workflows de PR têm concurrency, filtro de caminhos e timeout-minutes.
• O relatório de uso é comparado com a estimativa todo mês.

Abra as configurações de billing da sua organização agora: se o uso de Actions dobrar este mês, quem recebe o aviso, e em que dia?