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. Commented 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
    Commented 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. Commented 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. Commented 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. Commented 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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .