The crontab command has one of the worst UI problems:<p>1. "crontab -e" lets you edit your crontab file, and "crontab -r" deletes it (without asking). The two keys are next to each other.<p>2. "crontab" (no arg) reads the contents of the crontab file from stdin and replaces it. When you accidentally hit Ctrl-D after it, your crontab is replaced with an empty file.
Cronic (<a href="http://habilis.net/cronic/" rel="nofollow">http://habilis.net/cronic/</a>) has been a real life-saver when it comes to using cron in production services. I've been using it for 4+ years without looking back.
I never edit a crontab directly. I use external files and reinstall them with "crontab filename" as needed. Then of course the files can be revision-controlled.<p>Also, I name the files according to host so I remember exactly where they were installed in a networked environment (e.g. "host1.crontab", "host2.crontab").
0. Use systemd timers instead.<p>OnCalendar= has a less insane format than cron, exit code and output logging, locking, proper command line tools, and other niceties like Persistent= (catch up e.g. after system was powered off) etc.<p>(And yes, you can still have user "cronjobs" if you enable systemd user session lingering.)
A few notes that I think are worth going over:<p>1. mysqldump can require quite a few more permissions than mentioned, depending on your utilization of mysql<p>2. The best way I've found to test the cron-like environmentis by following this: <a href="http://stackoverflow.com/questions/2135478/how-to-simulate-the-environment-cron-executes-a-script-with" rel="nofollow">http://stackoverflow.com/questions/2135478/how-to-simulate-t...</a><p>Otherwise you run the risk of .profile (and similar) being loaded, where they will not be when run in the cron task.<p>3. Extra emphasis on using a lock file to avoid overlapping cron tasks!<p>4. I love using `time` or similar means to pass execution time somewhere (a log file, or a web hook), which helps with point 3.