Systemd Timers vs Cron: Quando Usar Cada Um em Produção Linux

systemd timers vs cron. Cron não morreu, mas systemd timers mudaram o jogo. Vamos separar por uso real, não por teoria.

Cron vs systemd timers: a diferença essencial

Quando cron ainda faz sentido

Cron não é errado, só é simples demais para alguns cenários.

Use cron quando:

✅ 1. Tarefas simples e estáveis

• Backup diário
• Limpeza de cache
• Rotação de logs customizada

0 3 * * * /usr/local/bin/backup.sh

✅ 2. Ambientes legados

• VPS antiga
• Containers simples
• Sistemas sem systemd (Alpine, BusyBox)

✅ 3. Scripts que não dependem de estado

Se falhar, falhou. Executa amanhã e pronto.

Onde cron começa a falhar (literalmente)

❌ Não sabe se rodou
❌ Não sabe se falhou
❌ Não reinicia
❌ Não respeita dependências
❌ Logs espalhados ou inexistentes

Em produção moderna, isso vira achismo operacional.

Quando systemd timers são a escolha certa

Se você roda AlmaLinux, Rocky, Debian, Ubuntu moderno → timers são superiores.

✅ 1. Tarefas críticas

• Jobs de billing
• Sincronizações
• Rotinas de segurança
• Scripts que não podem ser perdidos

# /etc/systemd/system/cleanup.timer
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

➡ Persistent=true = se o servidor estava desligado, executa ao voltar
Cron? Perdeu.

✅ 2. Quando você precisa saber o que aconteceu

systemctl status cleanup.service
journalctl -u cleanup.service

Isso é ouro em troubleshooting.

✅ 3. Dependência de serviços

Exemplo: só rodar quando:

• rede está ativa
• banco está no ar
• volume montado

[Unit]
After=network-online.target mariadb.service
Requires=network-online.target

Cron simplesmente ignora isso.

✅ 4. Controle de recursos

Evita script matando o servidor:

[Service]
CPUQuota=20%
MemoryMax=512M

Cron não tem nenhum controle nativo.

systemd timers ≠ complexidade (mito comum)

Sim, parece mais verboso.
Mas o ganho operacional é enorme.

Estrutura padrão:

• .service → o que executar
• .timer → quando executar

Depois disso:

systemctl enable --now cleanup.timer

Pronto. Muito mais previsível.

Comparação direta em cenário real

Backup diário em produção

Cron

• Rodou?
• Falhou?
• Demorou?
• Consumiu CPU demais?

🤷‍♂️ ninguém sabe sem gambiarra

systemd timer

• Status claro
• Logs centralizados
• Retry controlável
• Execução garantida

Regra prática (guarde essa)

🧠 Use cron apenas quando:

• Simples
• Não crítico
• Não depende de estado
• Ambiente limitado

🚀 Use systemd timers quando:

• Produção
• Missão crítica
• Precisa de logs, controle e previsibilidade
• Quer dormir tranquilo 😄

Dica de ouro (muita gente ignora)

👉 Nunca misture cron + systemd para a mesma tarefa
Isso gera:

• execuções duplicadas
• concorrência
• bugs intermitentes (os piores)

FAQ