Apps Script: Limite de 6 Minutos e Cotas Oficiais

Esse é o resumo. Os detalhes importam bastante se você está tentando automatizar qualquer coisa relevante em um modelo financeiro com múltiplas abas - ou se precisa entender por que a automação que o time de TI montou fica quebrando no meio do processo.

Os Números Oficiais das Cotas

De acordo com a documentação oficial de cotas do Apps Script (verificada em julho de 2026):

Gatilhos baseados em tempo têm limites diários separados:

Há ainda um limite de 30 execuções simultâneas por script. A Sheets API tem um limite de 300 requisições de escrita por minuto por projeto, conforme a página oficial de limites da Sheets API (verificada em julho de 2026). Quando esse limite é atingido, o Apps Script precisa esperar - o que consome o orçamento de tempo de execução antes mesmo de você ter feito algo útil.

O limite de 30 minutos para contas Workspace costuma ser citado como solução, mas não resolve o problema. Um script que precisa de 31 minutos ainda vai falhar.

Por Que Modelos de FP&A Batem Nesse Limite

Uma fórmula simples como =SOMASES ou =ÍNDICE/CORRESP não usa Apps Script de forma alguma. O problema começa quando você precisa fazer coisas que fórmulas não conseguem:

Loops de ingestão de dados. Buscar realizados de um endpoint REST linha por linha, cruzar com a aba Premissas! e gravar os resultados de volta. Um modelo de 24 meses com 40 linhas de resultado são no mínimo 960 chamadas individuais à Sheets API. Na latência típica, só isso já consome de 3 a 4 minutos, antes de qualquer lógica de cálculo.

Conciliação entre abas. Scripts que leem simultaneamente DRE, Balanço Patrimonial e Fluxo de Caixa, verificam se o lucro acumulado fecha e sinalizam divergências. Ler intervalos em múltiplas abas, fazer as comparações e gravar uma coluna de status de volta acumula tempo rapidamente.

Formatação de board pack. Percorrer 12 colunas mensais, aplicar formatação condicional, ocultar linhas zeradas, definir áreas de impressão e gerar PDFs. Só a etapa de geração de PDF com DriveApp.createFile() pode consumir de 45 a 90 segundos por aba.

Forçar atualização de IMPORTDATA. Como IMPORTDATA e IMPORTXML têm seus próprios problemas de atualização (veja Como Atualizar Google Sheets Automaticamente), alguns analistas usam scripts para apagar e reinserir a fórmula e forçar a recarga. Fazer isso em 15 células com um sleep entre cada uma consome o orçamento de tempo rapidamente.

O Que Realmente Mata Seu Script (Não É O Que Você Pensa)

O vilão óbvio é a quantidade de iterações do loop. O menos óbvio é o padrão de acesso a dados célula por célula.

Cada chamada a getValue() ou setValue() dentro de um loop gera uma ida e volta aos servidores do Google. Um script que faz isto:

// Lento: 1.000 chamadas de API para 500 linhas
for (let i = 2; i <= 501; i++) {
  let val = sheet.getRange(i, 3).getValue();      // 1 chamada de API
  sheet.getRange(i, 4).setValue(val * 1.085);     // 1 chamada de API
}

...faz 1.000 chamadas de API para 500 linhas. A aproximadamente 30ms por chamada em condições ideais, são 30 segundos só de I/O. Somando instabilidade de rede, recuo por cota e eventuais chamadas a Utilities.sleep() para evitar limite de taxa, você pode bater na parede em 300 linhas.

A solução é processar em lote:

// Rápido: apenas 2 chamadas de API no total
const data = sheet.getRange(2, 3, 500, 1).getValues();   // lê tudo de uma vez

// Aplica a taxa de crescimento em memória - nenhuma chamada de API no loop
const updated = data.map(row => [row[0] * 1.085]);

sheet.getRange(2, 4, 500, 1).setValues(updated);          // grava tudo de uma vez

Isso processa as mesmas 500 linhas em cerca de 200ms de I/O. A diferença é 30 segundos contra 0,2 segundos. Não estamos falando de micro-otimização: estamos falando se a atualização trimestral vai concluir ou não.

O Padrão de Continuação: Executando Além de 6 Minutos

Quando processar em lote ainda não basta - como ao lidar com 5.000 linhas ou operações em múltiplas etapas entre abas - a abordagem padrão é salvar o estado e reiniciar.

O Apps Script oferece PropertiesService.getScriptProperties() como armazenamento persistente entre execuções. Você salva o progresso, encerra a execução atual antes que o timer o faça, e agenda o próximo bloco.

function processarRealizadosComContinuacao() {
  const props = PropertiesService.getScriptProperties();
  const startTime = Date.now();
  const MAX_RUNTIME_MS = 5 * 60 * 1000; // 5 min - para antes dos 6 minutos

  // Retoma de onde parou, ou começa na linha 2
  let linhaAtual = parseInt(props.getProperty('ultimaLinha') || '2');

  const aba = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Realizados');
  const ultimaLinha = aba.getLastRow();

  while (linhaAtual <= ultimaLinha) {
    // Verifica o orçamento de tempo a cada 100 linhas
    if (linhaAtual % 100 === 0 && (Date.now() - startTime) > MAX_RUNTIME_MS) {
      props.setProperty('ultimaLinha', linhaAtual.toString()); // salva progresso
      // Agenda nova execução em 1 minuto
      ScriptApp.newTrigger('processarRealizadosComContinuacao')
        .timeBased()
        .after(60 * 1000)
        .create();
      return; // encerramento controlado
    }

    // Sua lógica de processamento aqui
    // ...

    linhaAtual++;
  }

  // Concluído - limpa o estado e remove gatilhos pendentes
  props.deleteProperty('ultimaLinha');
}

Isso funciona, mas tem custos reais: latência entre os blocos, acúmulo de gatilhos se você não fizer a limpeza e complexidade de depuração quando algo falha no meio da continuação. É a resposta certa quando você precisa dela, mas não é uma experiência de desenvolvimento agradável.

Outras Cotas que Aparecem Sem Avisar

O limite de 6 minutos é o mais conhecido, mas outros limites pegam pessoas em produção:

Taxa de leitura e escrita em planilhas: 300 requisições/minuto por projeto. Se o script chama getValues() em sequência rápida em várias abas, você vai atingir esse limite e precisará de Utilities.sleep(200) entre as chamadas, o que por sua vez piora o problema do tempo de execução.

Cota de e-mail: 100 e-mails/dia (consumidor) e 1.500/dia (Workspace). Um script de distribuição de board pack enviado para uma lista de 200 pessoas vai falhar em contas gratuitas.

Busca de URLs externas: UrlFetchApp tem um limite de 20.000 chamadas/dia e tamanho máximo de resposta de 50MB. Relevante se você está consultando dados de mercado ou feeds bancários.

Armazenamento de propriedades: PropertiesService armazena no máximo 500KB por script e 9KB por propriedade. Se você está serializando arrays grandes como estado de checkpoint, vai ultrapassar esse limite sem perceber.

Se Você Não Escreve o Código: O Que Perguntar ao TI

Você não precisa entender JavaScript para ter uma conversa produtiva com o time de desenvolvimento quando um script quebra. As perguntas certas permitem sair da reunião com um diagnóstico, não com um "vamos investigar".

Sobre como o script acessa os dados:

• O script lê e grava em bloco, ou célula por célula dentro de um loop? Scripts que fazem leitura célula por célula podem fazer mais de 1.000 chamadas de API para processar 500 linhas, o que os torna muito mais lentos e sujeitos a limite de tempo.
• Quantas chamadas à API o script faz por execução, aproximadamente?

Sobre o que acontece quando o script para:

• O script tem algum mecanismo de checkpoint? Se parar na linha 400 do meu modelo, ele retoma da linha 401 na próxima execução, ou começa do zero?
• Os gatilhos agendados são removidos depois que o processo termina? Gatilhos que não são limpos podem acumular e disparar o mesmo script várias vezes.

Sobre o plano da conta:

• A organização usa Google Workspace pago ou conta de consumidor (Gmail gratuito)? O limite de execução é cinco vezes maior no Workspace (30 minutos contra 6).
• O script usa gatilhos baseados em tempo? Qual é o tempo total acumulado de execução por dia? No plano gratuito, o teto é 90 minutos/dia para todos os gatilhos combinados.

Sobre o estado da planilha em caso de falha:

• Se o script parar no meio, a planilha fica com dados parciais? Quais abas podem ficar inconsistentes?
• Existe um log de execução acessível para identificar em qual linha ou etapa o script falhou?

Levar essas respostas para a próxima conversa com o TI transforma o diagnóstico de uma especulação em uma análise objetiva.

Perguntas Frequentes

Qual é o limite de execução do Apps Script para contas gratuitas? 6 minutos por execução, conforme a documentação oficial de cotas do Google (verificada em julho de 2026). O script é interrompido imediatamente ao atingir esse limite, sem salvar progresso parcial.

Contas Google Workspace têm um limite diferente? Sim. Contas pagas do Google Workspace têm limite de 30 minutos por execução - cinco vezes maior que o plano gratuito. O limite diário de tempo acumulado de gatilhos também é mais generoso: 6 horas/dia contra 90 minutos/dia no plano gratuito.

O que acontece com os dados da planilha quando o script é interrompido? Qualquer dado já gravado permanece na planilha. Qualquer dado ainda não gravado é perdido. Se o script estava atualizando um modelo de 800 linhas e parou na linha 400, as primeiras 400 têm os dados novos e as demais têm os dados antigos, sem nenhum aviso visível na tela.

Por que meu script quebra antes de 6 minutos? O motivo mais comum é o padrão de leitura e gravação célula por célula. Scripts que acessam dados individualmente dentro de loops fazem centenas de chamadas separadas à Sheets API, cada uma com latência de rede. Além disso, a Sheets API tem um limite de 300 requisições de escrita por minuto por projeto: ao atingir esse teto, o script precisa aguardar, consumindo o orçamento de tempo mesmo sem processar dados.

Como saber se o problema é o plano da conta ou o design do script? Verifique o log de execução do Apps Script (menu Extensões > Apps Script > Execuções). Se a mensagem de erro for Exceeded maximum execution time, é o limite de tempo de execução. Se for Quota exceeded com detalhes sobre requisições por minuto, é o limite de taxa da Sheets API. Os dois têm causas e soluções distintas.

Quando Parar de Lutar Contra a Cota

O padrão de continuação resolve o problema de tempo, mas não o de complexidade. Uma automação em múltiplas etapas que divide em blocos entre várias invocações de gatilho, salva estado no PropertiesService, limpa seus próprios gatilhos e trata falhas parciais de forma controlada se torna um projeto de software - não uma automação de planilha.

Para casos de uso de FP&A onde a lógica é complexa mas a interação é simples (por exemplo: "atualize minhas premissas de FCFF com os realizados deste trimestre e recalcule o valor terminal"), uma abordagem no lado do servidor contorna a cota completamente. Ferramentas como o ModelMonkey rodam fora do Apps Script: não há timer de 6 minutos, nenhuma gestão de tamanho de lote e nenhum token de continuação. Você descreve o que precisa acontecer no seu modelo de 8 abas, o ModelMonkey executa e grava os resultados de volta.

Isso nem sempre é a escolha certa. Se você tem um script que roda em 3 minutos, é acionado por um gatilho e nunca muda, não mexa nele. Mas se você está engenheirando em torno da cota, vale perguntar se esse tempo de desenvolvimento não seria melhor aplicado em outro lugar.

Resumindo

O limite de execução do Google Apps Script é de 6 minutos para contas de consumidor e 30 minutos para contas pagas do Google Workspace, conforme documentado na página oficial de cotas do Google. Modelos de FP&A atingem esse limite principalmente por padrões ineficientes de acesso à API (leituras e escritas célula por célula em vez de operações em lote) e automações complexas com múltiplas etapas. Processar em lote com getValues()/setValues() pode reduzir o tempo de execução em 10 a 20 vezes para tarefas de processamento de dados. Quando o processamento em lote não basta, o checkpoint de continuação via PropertiesService funciona, mas adiciona complexidade significativa. Scripts que quebram no meio do processo podem deixar a planilha em estado inconsistente, por isso é essencial confirmar com o time de TI se existe um mecanismo de retomada. Scripts que precisam de mais do que alguns minutos para rodar de forma confiável são candidatos a migrar para execução no lado do servidor.