Instead of typing "crontab -e" I accidentally typed "crontab" and was stuck in the middle of a process so I aborted the process. Now when I go to crontab -e it's entirely blank. This isn't good at all. If I can't get it back I will need to rewrite it.

Is there any way to:

  1. get my crontab jobs back? are they in memory somewhere? Where are the account specific crontab files located in linux? OR
  2. get a log of all things that cron has done, so I can reverse engineer my crontab file. I hadn't looked at it in a long time?
  • 3
    Just restore it from your most recent system backup. Jan 30, 2012 at 21:04
  • If you typed crontab -r like I did and found this thread, you can recover the command reading the logs from /var/log. In my case syslog.1 had everything that I needed
    – StackUnder
    Jul 25, 2013 at 13:40

5 Answers 5


crontab with no arguments reads a crontab file from standard input. For example, you might use:

 echo "* * * * *  run-this-every-minute" | crontab

Once you've clobbered your crontab (i.e., crontab -l shows nothing), there's no good way to get it back.

On my system (Ubuntu 11.04), personal crontabs are stored in /var/spool/cron/crontabs/<USER> -- but that's what you clobbered, so that won't do you any good. (The path could be different on your system.)

I see entries in /var/log/syslog for commands executed by cron; you might be able to reconstruct your crontab from that (or your system's equivalent, if any), but it's going to be tedious.

Here's what I do to avoid this kind of problem:

I keep my crontab in a separate file, maintained in a source control system. I install it only by running

crontab filename

I never use crontab -e. If I accidentally clobber my crontab, I can just reload it from the file. (Well, hardly ever; I sometimes use crontab -e to make temporary changes, knowing that I can restore the current version later.)

  • @mountainclimber: I disagree. To save your crontab, use crontab -l > filename. To restore it, crontab filename. Use the system-provided interface; don't go behind its back and manipulate system files. For one thing, updating the file won't necessarily tell the system to reread it; the crontab command will. For another, there may be differences between what's in the file and the output of crontab -l; on Ubuntu, the file has some extra comment lines advising you not to edit it. Oct 30, 2017 at 20:29
  • I'll delete my other comment. New comment: Keith mentions path /var/spool/cron/crontabs/<USER>. On SUSE, my path is slightly different (note extra slash): /var/spool/cron/cron/tabs/<USER>. Thought I would mention it for newbies to cron and linux like me. Keith's answer is correct. Oct 30, 2017 at 20:58

Script for full crontab recovery

I made a PHP script that does a full recovery of your crontab, based on the log.

It outputs a single instance of every cron command run by the user for the last week.

I put it here


Here is a sample output:

perl ~/sorttv/sorttv.pl


bash ~/scripts/sort_sports.sh


I'm sorry, but I can't help asking the obvious: why not restore it from backup?

Er, sorry, I see that was suggested already.


If your EDITOR envrionment variable is EDITOR=vi, try

vi -r

to recover the session. Do not directly write the saved session, if you get one, to your crontab directory. Use it as a guide to recreate your crontab using

crontab -e

Note: Since you did not specify an OS, Solaris and other UNIX OSes do not recognize changes to crontab files except those created through crontab -e. If I remember correctly, Linux does.

  • There is no session to recover; the OP typed crontab rather than crontab -e. See my answer fora better (IMHO) way to maintain your crontab. Jan 30, 2012 at 21:40

Great answer from @Keith Thompson - good idea reconstructing from /var/log/syslog!

I also accidentally clobbered my user crontab but was able to reconstruct it with the following script-fu

mkdir ~/syslog
sudo cp /var/log/syslog* ~/syslog/
sudo chmod 777 ~/syslog/*
cat ~/syslog/* | grep "(username)" | grep -o "CMD.*" | sort | uniq

where username should be replaced with the user whose crontab you want to reconstruct.

Note that you may need to gunzip the contents of your /var/log/syslog.x.gz files first if the logs have been compressed (ubuntu zips up syslog.2+)

This will also only get commands that are still in the logs, which will be about the last 7 days... so if you have a monthly task that didn't run... that one is probably gone

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.