Como usei GitHub Actions para melhorar a UX a custo zero

1. A Inviabilidade

A maioria dos clientes, ao contratar a construção de um software, espera que tomemos as melhores decisões possíveis para o negócio deles. Para grandes corporações, custos de infraestrutura são previstos, mas para pequenas empresas, pagar por uma hospedagem robusta para um sistema de uso esporádico pode inviabilizar o projeto.

Nesse cenário, serviços serverless e planos free tier parecem a saída perfeita. Mas eles ainda possuem problemas.

2. O problema do Cold Start

O grande problema dessas abordagens gratuitas é a hibernação. Quando o sistema fica inativo, a server para. O primeiro acesso do dia, ou um acesso depois de um hiato, traz uma demora frustrante.

Para o usuário final, isso pode ser um problema da aplicação. A demora gera dúvidas como se o sistema caiu. Essa perda de agilidade e a incerteza atrapalham o dia a dia da empresa, criando uma experiência de uso ruim para uma ferramenta que deveria agilizar processos.

3. Opções de Resolução

Focado em resolver essa dor sem gerar custos extras para o cliente, comecei a buscar formas de manter o serviço ativo.

Minha primeira tentativa foi o cronjob.org. Aparentemente funcionava bem, mas comecei a notar falhas. Ocasionalmente, o servidor desligava e o serviço simples de requisições não tinha robustez suficiente para ligar novamente o servidor, apenas para o manter ligado. Eu precisava de algo que não apenas chegasse no servidor, mas que garantisse que ele acordasse.

4. GitHub Actions como Infraestrutura

Foi pesquisando que percebi o potencial do GitHub Actions. Ele permite agendamentos e execução de scripts.

Criei um workflow (acordar.yml) com uma estratégia:

Comando: Em vez de um GET comum, usei curl configurado com headers específicos e, o mais importante, retries, que é o que realmente faz funcionar. Se o servidor demorasse a responder (o que acontece geralmente), o script tentava de novo automaticamente até obter sucesso.
Recursos: Para não estourar os limites de minutos gratuitos do GitHub Actions (e do próprio servidor de hospedagem), configurei o cron para rodar de 14 em 14 minutos.
Horário Comercial: O script só roda nos dias e horários exatos de funcionamento da empresa. De noite e fins de semana, o servidor dorme.

name: Acordar Site

on:
  schedule:
    # Roda a cada 14 min, das 11h as 22h UTC (08h as 19h Brasil)
    # De Segunda (1) a Sabado (6)
    - cron: '*/14 11-22 * * 1-6'
  workflow_dispatch: # Permite rodar manualmente

jobs:
  wake_up:
    runs-on: ubuntu-latest
    steps:
      - name: Acordar Tudo
        run: |
          # BACKEND
          curl -I -L -X GET "https://xxxxx" \
          -H "User-Agent: xxxxxxxxxxx" \
          -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
          --retry 3 \
          --retry-delay 5 \
          --max-time 60
          #FRONTEND
          curl -I -L -X GET "https://xxxxx" \
          -H "User-Agent: xxxxxxxxxxx" \
          -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
          --retry 3 \
          --retry-delay 5 \
          --max-time 60

Após rodar a primeira execução manual, o sistema passou a funcionar perfeitamente.

Agora o cliente tem um software que está sempre pronto quando eles precisam, sem a dor de cabeça da lentidão inicial e, crucialmente para o escopo do projeto, sem custos fixos mensais de hospedagem.

Essa foi minha pequena jornada para transformar em algo viável esse software.

Bônus: A regra dos 60 dias

E para garantir que o cliente nunca precise me ligar porque o GitHub desativou o agendamento por inatividade (regra dos 60 dias), criei um segundo workflow mensal. Ele funciona como um batimento cardíaco, fazendo um pequeno commit automático apenas para comunicar ao GitHub que o sistema continua ativo.

name: Manutenção Preventiva (Keepalive)

on:
  schedule:
    # Roda as 00:00 do dia 1 de cada mês
    - cron: "0 0 1 * *"
  workflow_dispatch: # Permite rodar manualmente

jobs:
  auto-commit:
    runs-on: ubuntu-latest
    permissions:
      contents: write #permissão para commit

    steps:
      - uses: actions/checkout@v3

      - name: Atualizar timestamp para evitar inatividade
        run: |
          date > last_activity.txt
          git config user.name "GitHub Actions Bot"
          git config user.email "[email protected]"
          git add last_activity.txt
          git commit -m "chore: atividade mensal automatica"
          git push

Também gostaria de destacar que sei que essa resolução não se aplica a casos de médias empresas, apenas sistemas que realmente terão menos usuários e pouco tráfego. Meu objetivo aqui não é criar uma bala de prata para custo zero, é apenas aplicar uma solução para um caso específico de pequenas/microempresas.