Ejecutas seis instancias de un servicio y necesitas que un proceso nocturno corra exactamente una vez. ¿Cómo lo montas?

No confíes en que cada instancia tenga un cron local. Usa un bloqueo de líder, como una fila o una clave adquirida con un arrendamiento y un tiempo de vida, de modo que solo lo ejecute quien lo tiene, o delega la planificación en un cron de plataforma que encole un único trabajo para que lo recoja un worker. En cualquier caso, haz el proceso idempotente y observable, porque un arrendamiento puede caducar a mitad de ejecución y provocar solapamiento.

La versión ingenua corre seis veces, y la versión donde se designa una instancia especial deja de funcionar el día que esa instancia no está sana. Así que o uso un bloqueo o saco la planificación de la aplicación por completo. Con bloqueo, cada instancia intenta adquirir un arrendamiento a la hora prevista, normalmente un insert o un update condicional sobre una tabla de trabajos con caducidad, y solo corre el ganador, renovando el arrendamiento mientras trabaja. La sutileza es que un arrendamiento puede caducar durante una ejecución larga y entonces arranca una segunda instancia, así que el proceso sigue teniendo que ser seguro de ejecutar dos veces. Mi preferencia a cualquier escala es el segundo enfoque: planificación a nivel de plataforma que encola un único mensaje, y workers normales que lo consumen. Eso da reintentos, visibilidad e historial gratis, y el código de aplicación se queda en un simple manejador. Sea como sea, registro las horas de inicio y fin y aviso cuando un proceso no ha terminado dentro de su ventana esperada, porque un proceso que deja de correr sin ruido es el fallo del que la gente se entera semanas después.