Todo guard tem dois estados: funcionando e verde por acidente. Os dois imprimem “OK”. A diferença só aparece quando você força a condição que ele deveria pegar.
pgrep -f meu-servico dentro do próprio watchdog casa com o próprio shell que
roda o comando. O guard vê 1 processo, conclui “está vivo” e nunca relança nada — inclusive quando
o serviço está morto.
pgrep -f '[m]eu-servico' # o colchete impede o auto-match
Melhor: varra /proc/<pid>/cmdline excluindo $$ e
$PPID, e confirme com uma segunda evidência (idade do log, estado do serviço).
Um guard de sessão que reporta chats_ativos=0 está dizendo “nada a fazer” — ou
“estou lendo o banco errado”. Se há três grupos conversando e o guard conta zero, o número é
sintoma, não sossego.
Antes de confiar num zero, confirme a fonte: o arquivo que o guard lê é o mesmo que o processo escreve? Um store com 0 linhas deixa o guard verde para sempre.
Um gate de memória com piso fixo (digamos 4.600 MB) numa máquina que mede 10.800 MB e 4.100 MB em minutos seguidos bloqueia metade das execuções — e você culpa o serviço.
Dimensione o gate pela mínima observada com margem explícita (1 tarefa = 400-800 MB → piso de 2.000 MB dá 2,5x de folga). Meça duas vezes, em minutos diferentes, antes de escolher o número.
Deduplicação por hash do texto reenvia a mesma mensagem toda vez que o texto muda — e o texto muda a cada tick, porque o agente continua trabalhando. Resultado: o grupo recebe a mesma notificação várias vezes.
Entrega perdida é um evento: deduplique por (canal, timestamp_de_prontidão),
e grave a chave também quando o reenvio falha — senão repete para sempre.
Ver a skill Roger MLOps Guard Ver todas as skills
Quer isso montado no seu projeto? Setup guiado a partir de R$ 1.500, com o primeiro ciclo rodado junto.
Sai quando eu publicar, junto com a skill grátis usada aqui. Sem spam, e o descadastro é de um clique.