Downsides of cron
Cron is the standard unix program for scheduling jobs, but it's not well suited for this
task. Cron has no ability to reschedule failed jobs, and it throws away the program
termination status. Cron can save command output, but your only built in option is to
email it somewhere, and because of what I just mentioned, it's all or nothing. You can't
send based off of exit code. Even if you want this you still have to mess around with
configuring email. Alternatively you can try to remember to add something like
'&>"job_name_$(date)"'
to the end of each command in your crontab. That's better than email,
but a chore, and you still have to manually check the output anyways. I used to do this
but didn't check it regularly enough, and found out that my backup script hadn't run in
over a week.
So cron is perfect if you want to run a job periodically, but don't really care if it actually runs.
Existing Alternatives
Another option is to write a service file for your init system. This may or may not be too bad. I use systemd and after looking through the configuration options it didn't look like it would be able to do everything I want.
Or you could use some other program. What I want is something straight forward, not written in a memory hog language like python, with no horrible Unix style config files, and no domain specific languages. I couldn't find that out there, which is pretty strange since this seems like a common problem that isn't very hard, so I figured I'd just write it myself.
Would You Like To Know More?
For more details, check out the project, but briefly the idea is that you edit and recompile the C code yourself, adding your own functions. The functions schedule themselves by giving Unix timestamps back to the main loop. What your functions do is up to you, but the program comes with a set of functions that help you reschedule and manage running commands. The program is only a few hundred lines, and tries to be very simple so you can modify it to your needs.