MÓDULO 2.6

🌙 Primeiro cron: backup diário automático

Hello World pragmático do Hermes: o cron mais útil e mais seguro pra começar. Sintaxe natural, timezone, permissões e como verificar que rodou.

6
Tópicos
25
Minutos
Prático
Nível
Hands-on
Tipo
1

🛡️ Por que esse é o primeiro cron

Backup diário pro GitHub é o cron de menor risco e maior valor que você pode criar no dia 1. Ele só faz git add && commit && push dentro de ~/.hermes. Não toca em sistema, não chama API externa de risco, não gasta tokens caros, não tem efeito colateral além de subir um commit.

⚖️Por que NÃO começar com cron ambicioso

  • "Responder email automaticamente" → risco alto de enviar mensagem errada antes de você confiar
  • "Postar conteúdo no Twitter/IG" → impacto público se errar tom
  • "Pagar boleto/agendar transferência" → financeiro merece muita validação manual
  • "Backup pro GitHub" → puramente útil, zero efeito colateral, falha é silenciosa

✓Princípio de progressão

Começar pelo cron mais útil e mais seguro testa o sistema inteiro (gateway → AIAgent → tools → permissions → entrega) sem pôr nada importante em risco. Se funcionar, você ganha confiança e proteção real. Se quebrar, você não perde nada além de tempo de debug.

2

💬 Sintaxe natural via Telegram

A forma mais rápida de criar um cron: comando slash no Telegram. Você não precisa decorar a sintaxe cron clássica (0 0 * * *) — Hermes interpreta linguagem natural e gera o job estruturado.

📤 Comando completo

/cron add "every 1d at 00:00" "Faça commit com timestamp e push das mudanças do agente para o GitHub. Use mensagem 'Backup automático {data}'. Se não houver mudanças, apenas reporte 'Sem alterações'."

🕐 Sintaxes aceitas

  • "every 30m" — a cada 30 minutos
  • "every 2h" — a cada 2 horas
  • "every 1d at 09:00" — diariamente às 9h
  • "every 1d at 00:00" — diariamente meia-noite
  • "every monday at 08:00" — toda segunda às 8h
  • "weekly" — uma vez por semana

🔧Comandos relacionados

  • /cron list — todos os jobs agendados, com next_run_at
  • /cron remove ID — apaga um job
  • /cron run ID — força execução agora (útil pra testar)
  • /cron pause ID / /cron resume ID — pausar temporariamente
3

⌨️ Sintaxe CLI: hermes cron create

Equivalente CLI da criação de cron. Mais explícito que o slash command — ideal para script de provisioning idempotente quando você for replicar o setup em outro VPS. Pode versionar como bootstrap.sh e rodar em ambientes novos.

⚡ Comando equivalente

docker exec -it hermes hermes cron create \
  "every 1d at 00:00" \
  "Backup do agente: commit + push das mudanças" \
  --workdir /root/.hermes \
  --deliver telegram \
  --name backup-diario

🚩 Flags principais

FlagFunção
--workdir <path>cwd do job; carrega AGENTS.md/CLAUDE.md daqui
--deliver <plat>destino: telegram, discord, all, origin
--skill <name>injeta skill no início da sessão fresh
--no-agentscript-only sem LLM (pra watchdogs)
--script <path>(com --no-agent) script .sh ou .py a executar
--name <str>identificador legível pra você (default: gerado)

💡Telegram vs CLI: quando usar qual

Telegram = exploração interativa, feedback imediato, ajuste rápido. CLI = automação, replicação, scripts de bootstrap. Pra criar 1 cron, Telegram é mais rápido. Pra subir 10 crons numa VPS nova, CLI num .sh é determinístico.

4

🌍 Timezone: UTC vs local

Pegadinha clássica: container Docker roda em UTC por padrão. "every 1d at 00:00" dispara à meia-noite UTC, que é 21:00 do dia anterior em Brasília (UTC-3). Cron rodando 3 horas antes do esperado destrói percepção e bagunça logs.

🛠️ Duas formas de configurar

# Opção 1: env var no docker-compose.yml (preferida)
services:
  hermes:
    environment:
      - TZ=America/Sao_Paulo

# Opção 2: config.yaml dentro de ~/.hermes/
timezone: "America/Sao_Paulo"

# Após mudar, restart
docker compose restart

# Verificar timezone ativo
docker exec hermes date
# Esperado: "Sun May 10 18:32:00 -03 2026" (não UTC)

🗺️IANA timezone strings comuns

  • America/Sao_Paulo — Brasil sudeste (UTC-3)
  • America/Bahia — Bahia (UTC-3, mesmo offset)
  • America/Manaus — Amazonas (UTC-4)
  • Europe/Lisbon — Portugal (UTC+0/+1 com DST)
  • UTC — meridiano de Greenwich (default container)

⚠️Sintoma típico

"Marquei o cron pra meia-noite mas ele rodou às 21h." Container ainda em UTC. Hermes injeta timezone do sistema no system prompt — sem TZ certo, ele "pensa" estar 3 horas adiantado. Configurar timezone certo no início economiza muito retrabalho.

5

✅ Permissões: always allow git push

Na primeira execução do cron, Hermes vai pedir permissão pra rodar git commit e git push. Marque "always allow" — é uma ação segura, recorrente, com escopo travado pelo PAT fine-grained do módulo 2.5.

🤝Por que confiar nessa permissão

  • Token cirúrgico: só permite mexer em 1 repo (o de backup)
  • Operação reversível: commits sempre podem ser revertidos com git revert
  • .gitignore protege segredos: mesmo se commit estranho, .env não vai junto
  • Audit trail: cada push fica registrado no GitHub com timestamp
  • Sem "always": cron diário trava esperando você responder — quebra o propósito

🔍 Auditar permissões periodicamente

# Listar permissões aprovadas
docker exec hermes hermes permissions list

# Revogar uma específica
docker exec hermes hermes permissions revoke ID

# Arquivo bruto (raramente preciso)
docker exec hermes cat /root/.hermes/permissions.json

📋Checklist mensal de auditoria

  • Listar permissions e revogar as que você não reconhece
  • Confirmar que tokens (GitHub, OpenRouter) ainda estão ativos e com escopo certo
  • Olhar último push no GitHub — algum dia sem backup?
  • Verificar ~/.hermes/logs/ por erros recorrentes
6

🔍 Verificação: /cron list, logs, GitHub

"Achar que rodou" é diferente de "ter rodado". Confirmar com fato fecha o loop. Três pontos de verificação: /cron list (mostra próximo run), logs (mostram execução), GitHub (mostra commit real).

✓ Checklist de verificação

# 1. Cron está agendado?
/cron list   # via Telegram, ou:
docker exec hermes hermes cron list

# 2. Forçar execução agora pra testar (não esperar 24h)
docker exec hermes hermes cron run backup-diario

# 3. Ver logs do tick
docker exec hermes tail -50 /root/.hermes/logs/cron.log

# 4. Conferir commit real no GitHub
# Abre o repo no browser, vê commits do dia

# 5. Buscar histórico via session_search
"Mostre as últimas execuções do cron de backup"

📁Onde fica o estado do cron

  • ~/.hermes/cron/jobs.json — todos os jobs com next_run_at
  • ~/.hermes/cron/.tick.lock — lockfile previne double-run
  • ~/.hermes/logs/cron.log — execuções, erros, exit codes
  • ~/.hermes/state.db — sessões SQLite com histórico de cada cron

🔧Se não rodou no horário esperado

  • Container parou: docker ps; se off, docker compose up -d
  • Timezone errado: docker exec hermes date, ajustar TZ se UTC
  • Lock file travado: apagar ~/.hermes/cron/.tick.lock e restart
  • Permissão bloqueada: ver permissions list, marcar always allow
  • Token expirado: regere PAT no GitHub, atualize via config set

🎯Resumo do módulo

✓
Backup diário pro GitHub é o cron ideal pra começar — risco baixo, valor alto, testa o sistema inteiro.
✓
Sintaxe natural via /cron add — "every 1d at 00:00" + descrição da tarefa.
✓
CLI hermes cron create para automação — flags: --workdir, --deliver, --skill, --name.
✓
TZ=America/Sao_Paulo evita 3h de defasagem — container default é UTC.
✓
Always allow para git push (token cirúrgico) — auditar mensalmente.
✓
Verificação tripla: /cron list + logs + GitHub — fechar o loop com fato, não suposição.

Próxima trilha:

Trilha 3 - 🏛️ Os 6 pilares do Hermes (Soul, Memory, Skills, Crons, Permissions, Sessions)

← Módulo Anterior Próxima Trilha: Pilares →