El enfoque de OnFailure= con systemd es sólido, pero se queda corto cuando el fallo no es un exit code distinto de cero. Un script que devuelve 0 tras hacer un rsync parcial o que deja un backup corrupto no dispara nada. Ahí es donde OnFailure te da una falsa sensación de cobertura.
Sobre la deuda técnica del crontab: el problema no es cronic ni la cantidad de líneas, es que la mayoría de la gente mete lógica de negocio dentro del cron. Si cada entrada es un one-liner que llama a un script versionado en git con su propio --dry-run, --verbose y tests, el crontab es solo un dispatcher y da igual que tenga 5 o 50 líneas. Lo que no se toca es lo que no está en control de versiones.
Alternativa que casi nadie menciona: systemd timers con Persistent=true para no perder ejecuciones si la máquina estaba apagada. Eso con cron lo tienes que implementar a mano con anacron o similar, y ahí sí que empieza el infierno.
Pregunta concreta: ¿cómo gestionáis la idempotencia cuando un job falla a mitad? Porque ni Prometheus ni OnFailure te arreglan un estado inconsistente en el destino.
