Resumo

  • O consumo dos trabalhos hospedados sujeitos à cota do GitLab.com pertence ao namespace de nível superior do projeto. Projetos e subgrupos separados podem, portanto, disputar a mesma folga.
  • Minutos adicionais são usados depois da franquia mensal e o saldo não consumido passa aos meses seguintes. A compra, porém, não é renovada mensalmente nem pode ser transferida entre grupos.
  • A capacidade de pagar pela execução não substitui a disponibilidade de um runner adequado nem a permissão segura para executar código. A alternativa de operar runners próprios também traz responsabilidades.

Uma folga que funciona em um lugar só

Ter saldo na empresa não é necessariamente ter saldo no lugar em que o trabalho precisa rodar. No GitLab.com, a compra de minutos adicionais tem um destino definido: o grupo ao qual está vinculada. A regra comercial não permite transferir esses minutos entre grupos.

Isso torna possível uma situação aparentemente contraditória: manter minutos comprados sem uso em um grupo e precisar comprar mais em outro. Trata-se de uma consequência possível da regra, não de um prejuízo identificado em uma empresa. Um relatório financeiro que some os dois saldos não modifica o direito de uso de nenhum deles.

Dentro da fronteira, por sua vez, o comportamento é de uma reserva compartilhada. Projetos distintos podem consumir uma mesma cota de execução. A plataforma, portanto, combina compartilhamento interno com separação externa. Comprar bem exige entender os dois lados: quem pode gastar a folga comum e onde uma folga já comprada deixa de estar disponível.

Essa questão não se resume ao preço de um minuto. Ela aparece na organização dos projetos, no aviso enviado a um responsável e no tempo necessário para autorizar uma reposição. Uma decisão que parece apenas administrativa pode determinar quais equipes ficam expostas ao mesmo ponto de interrupção.

A autonomia do projeto não cria uma cota própria

O modelo de namespaces organiza projetos em espaços de usuário ou de grupo. Grupos podem ter subgrupos, que herdam algumas configurações e mantêm outras próprias. Essa divisão ajuda a organizar o trabalho, mas não significa que cada subdivisão ganhe uma franquia independente de nível superior.

A documentação de consumo atribui os minutos ao namespace de nível superior do projeto em que o trabalho é executado. Não importa apenas quem apertou o botão: um colaborador que inicia uma execução em um projeto alheio não passa automaticamente a pagá-la com sua cota pessoal.

Considere dois projetos hipotéticos, um de produto e outro de ferramentas internas, dentro do mesmo grupo superior. Suas equipes podem planejar entregas separadamente, revisar códigos diferentes e prestar contas a gestores distintos. Ainda assim, o consumo dos trabalhos abrangidos pela cota reduz o mesmo saldo. O vínculo econômico existe mesmo sem uma dependência direta entre os respectivos programas.

Há uma boa razão para compartilhar. Quando as atividades se alternam, a reserva comum acomoda um pico sem exigir que cada equipe mantenha sua própria sobra. A mesma configuração pode, entretanto, concentrar a pressão quando várias equipes aumentam o uso ao mesmo tempo. O mérito da escolha depende da variação da demanda e da capacidade de coordená-la, não de uma preferência abstrata por centralização.

Uma entrega mais rápida pode consumir mais minutos

O nome da unidade facilita um erro de leitura. Minutos de computação não equivalem ao tempo que a pessoa esperou pelo resultado. O cálculo de cada trabalho divide sua duração em segundos por sessenta e aplica um fator de custo. O período em estado criado ou pendente não entra na conta. O total da sequência de integração soma os trabalhos que rodaram, inclusive os simultâneos.

Em uma conta ilustrativa, três trabalhos de dez minutos executados em paralelo, todos com fator um, consomem trinta minutos de computação. O intervalo de execução pode ser de dez minutos. Não há outros trabalhos ou tempos adicionais nessa hipótese. Ela serve para distinguir as unidades, não para estimar desempenho, economia ou a fatura de um cliente.

Reduzir a espera pode justificar o uso de mais recursos. Mas não se deve registrar a melhora de prazo como uma redução automática do consumo. A orientação de eficiência aborda caminho crítico, dependências, preparação de ambientes, recursos das máquinas e trabalho desnecessário. Distribuir testes entre máquinas e eliminar uma repetição são mudanças diferentes, embora ambas possam deixar o resultado disponível mais cedo.

O responsável pela cota comum precisa enxergar também o conteúdo do trabalho. Uma equipe que faz verificações indispensáveis pode consumir mais do que outra cuja entrega parece rápida porque verifica menos. O contador informa uso; não distingue, sozinho, a repetição inútil da validação que sustenta uma decisão importante.

O esgotamento tem uma ordem documentada

As regras da cota para runners de instância preveem avisos quando resta menos de 25%, menos de 5% e quando o saldo chega a zero. Os proprietários do namespace recebem e-mail, e a aplicação exibe uma notificação. Quem recebe o aviso pode não ser quem decide iniciar as próximas dezenas de trabalhos.

Esgotada a cota aplicável, os runners de instância deixam de processar novos trabalhos. Os pendentes ou reexecutados que dependem desses runners, mesmo em sequências já iniciadas, são descartados. Trabalhos em andamento podem continuar até o uso agregado do namespace ultrapassar a cota em mil minutos de computação; depois desse limite, os que ainda estão rodando também são descartados.

Não se trata de mil minutos extras para cada projeto. A tolerância é agregada e condicional. Outros trabalhos podem consumir o mesmo espaço durante a execução, e ter começado antes não assegura que uma sequência terminará. Os runners de projeto e de grupo não estão sujeitos a essa cota específica e continuam processando trabalhos.

É importante não chamar todo bloqueio desse tipo de indisponibilidade do fornecedor. A infraestrutura pode funcionar conforme a documentação, enquanto o cliente já não dispõe da autorização econômica necessária para continuar naquele caminho. A resposta, então, pode depender de reposição de cota ou revisão do trabalho, e não de recuperação de um serviço quebrado.

Essa diferença muda para quem o problema deve ser encaminhado. A equipe operacional pode identificar a causa sem ter permissão de compra. O gestor financeiro pode aprovar a despesa sem saber quais testes não podem esperar. O tempo entre essas duas decisões faz parte da exposição do comprador, embora não apareça como linha separada no preço dos minutos.

A reserva também tem idade

Os minutos adicionais entram em uso depois da franquia mensal incluída. O que não for consumido passa adiante, mas o pacote é uma compra pontual: não reaparece inteiro a cada mês. A documentação informa ainda que a reserva permanece disponível quando há mudança de plano, inclusive para Free.

O prazo declarado de validade é de doze meses a partir da compra. Atualmente, GitLab não aplica a expiração, mas também não garante validade após esse prazo. Isso não autoriza concluir que todo saldo antigo já foi eliminado. Tampouco transforma uma regra hoje não aplicada em promessa de reserva permanente.

Um registro útil deve combinar grupo de destino, data de compra e saldo de cada modalidade. A compra exige o papel de proprietário do grupo ou de administrador da conta de cobrança, com a conta ligada à assinatura do namespace. O fato de um projeto precisar de mais capacidade não concede, por si só, essas atribuições a quem trabalha nele.

Não decorre daí uma recomendação automática de mover projetos. As fontes examinadas não estabelecem todas as consequências de uma migração, e a organização dos repositórios envolve permissões e colaboração além da cota. A conclusão sustentada é que o local das próximas compras precisa corresponder ao local esperado de consumo. O saldo existente não pode ser tratado como dinheiro livremente redistribuível.

Pagar, encontrar uma máquina e poder executar

Runners são os ambientes que processam os trabalhos. A visão geral do produto separa a gestão do runner de seu âmbito de uso. Compatibilidade de etiquetas, estado, capacidade e recursos também entram na seleção. Aumentar o saldo não torna qualquer runner apto a qualquer trabalho.

Os runners hospedados poupam um trabalho operacional concreto: no funcionamento normal do GitLab.com, cada job recebe uma máquina virtual nova, removida depois. Arranjos especiais de contribuição comunitária têm características distintas. A documentação traz ainda a meta de iniciar 90% dos trabalhos em até 120 segundos. É um objetivo de serviço, não uma medição feita aqui nem uma garantia individual de início para a próxima execução.

Há também o limite da confiança. Um pedido de integração originado em um fork normalmente usa os recursos desse fork. Um membro com permissão pode iniciar a execução no projeto principal, combinando a configuração da ramificação externa com o contexto e os recursos do projeto principal. A documentação de merge requests alerta para a revisão de código não confiável. Recursos protegidos mantêm regras próprias; a descrição não significa que qualquer execução no projeto principal tenha acesso a todos os segredos.

Usar runners administrados pelo cliente fora dessa cota também não elimina o problema operacional. A orientação de segurança trata da proteção dos hosts, das redes, dos executores e do isolamento. Reutilizar ambientes não efêmeros entre projetos pode criar riscos que precisam ser avaliados. Sair de um medidor não faz desaparecer capacidade, manutenção ou responsabilidade.

As estatísticas de CI/CD ajudam a acompanhar duração e resultados das sequências. Elas respondem a perguntas diferentes das do contador do namespace. A compra faz sentido quando as duas visões se encontram: trabalho necessário, saldo utilizável no lugar certo e condições apropriadas de execução. Um total elevado de minutos, isoladamente, não comprova nenhuma dessas combinações.

Fontes e limites da análise

Foram examinadas, em 3 de setembro de 2026, as páginas oficiais sobre minutos de computação, aplicação da cota, compras adicionais, namespaces e eficiência.

As distinções de execução usam a documentação de runners, ambientes hospedados, pedidos de integração, segurança e análise de CI/CD. Não houve acesso a faturas de clientes, telemetria privada ou contratos negociados. A discussão da cota se refere ao GitLab.com, sem estender essas condições a toda instalação Self-Managed ou Dedicated.