Você roda seis instâncias de um serviço e precisa que um job noturno rode exatamente uma vez. Como você organiza isso?

Não confie em cada instância rodando um cron local. Use um lock de liderança, como uma linha ou chave adquirida com um lease e um tempo de vida, para que só quem o detém rode o job, ou delegue o agendamento a um cron no nível da plataforma que enfileira um job para um worker pegar. De qualquer forma, torne o job idempotente e observável, porque um lease pode expirar no meio da execução e causar sobreposição.

A versão ingênua roda seis vezes, e a versão em que uma instância especial é designada para de funcionar no dia em que essa instância fica com problema. Então eu ou uso um lock ou tiro o agendamento da aplicação por completo. Com lock, cada instância tenta adquirir um lease no horário agendado, tipicamente um insert ou um update condicional numa tabela de jobs com expiração, e só o vencedor roda, renovando o lease enquanto trabalha. A sutileza é que um lease pode expirar durante uma execução longa, e aí uma segunda instância começa, então o job ainda precisa ser seguro de rodar duas vezes. Minha preferência em qualquer escala é a segunda abordagem: agendamento no nível da plataforma que enfileira uma única mensagem, e workers comuns a consomem. Isso dá retries, visibilidade e histórico de graça, e o código da aplicação vira apenas um handler. De um jeito ou de outro, eu registro horários de início e fim e alerto quando um job não terminou dentro da janela esperada, porque um job que para de rodar em silêncio é a falha que as pessoas notam semanas depois.