This is the official manual for the latest Org-mode release.
Some tasks need to be repeated again and again. Org mode helps to organize such tasks using a so-called repeater in a DEADLINE, SCHEDULED, or plain timestamp. In the following example
** TODO Pay the rent DEADLINE: <2005-10-01 Sat +1m>
+1m is a repeater; the intended interpretation is that the task
has a deadline on <2005-10-01> and repeats itself every (one) month starting
from that time. You can use yearly, monthly, weekly, daily and hourly repeat
cookies by using the
y/w/m/d/h letters. If you need both a repeater
and a special warning period in a deadline entry, the repeater should come
first and the warning period last:
DEADLINE: <2005-10-01 Sat +1m -3d>.
Deadlines and scheduled items produce entries in the agenda when they are over-due, so it is important to be able to mark such an entry as completed once you have done so. When you mark a DEADLINE or a SCHEDULE with the TODO keyword DONE, it will no longer produce entries in the agenda. The problem with this is, however, that then also the next instance of the repeated entry will not be active. Org mode deals with this in the following way: When you try to mark such an entry DONE (using C-c C-t), it will shift the base date of the repeating timestamp by the repeater interval, and immediately set the entry state back to TODO1. In the example above, setting the state to DONE would actually switch the date like this:
** TODO Pay the rent DEADLINE: <2005-11-01 Tue +1m>
To mark a task with a repeater as
DONE, use C-- 1 C-c C-t
org-todo with a numeric prefix argument of -1.)
A timestamp2 will be added under the deadline, to keep a record that you actually acted on the previous instance of this deadline.
As a consequence of shifting the base date, this entry will no longer be visible in the agenda when checking past dates, but all future instances will be visible.
With the ‘+1m’ cookie, the date shift will always be exactly one month. So if you have not paid the rent for three months, marking this entry DONE will still keep it as an overdue deadline. Depending on the task, this may not be the best way to handle it. For example, if you forgot to call your father for 3 weeks, it does not make sense to call him 3 times in a single day to make up for it. Finally, there are tasks like changing batteries which should always repeat a certain time after the last time you did it. For these tasks, Org mode has special repeaters ‘++’ and ‘.+’. For example:
** TODO Call Father DEADLINE: <2008-02-10 Sun ++1w> Marking this DONE will shift the date by at least one week, but also by as many weeks as it takes to get this date into the future. However, it stays on a Sunday, even if you called and marked it done on Saturday. ** TODO Empty kitchen trash DEADLINE: <2008-02-08 Fri 20:00 ++1d> Marking this DONE will shift the date by at least one day, and also by as many days as it takes to get the timestamp into the future. Since there is a time in the timestamp, the next deadline in the future will be on today's date if you complete the task before 20:00. ** TODO Check the batteries in the smoke detectors DEADLINE: <2005-11-01 Tue .+1m> Marking this DONE will shift the date to one month after today.
You may have both scheduling and deadline information for a specific task.
If the repeater is set for the scheduling information only, you probably want
the repeater to be ignored after the deadline. If so, set the variable
repeated-after-deadline. However, any scheduling information without
a repeater is no longer relevant once the task is done, and thus, removed
upon repeating the task. If you want both scheduling and deadline
information to repeat after the same interval, set the same repeater for both
An alternative to using a repeater is to create a number of copies of a task subtree, with dates shifted in each copy. The command C-c C-x c was created for this purpose, it is described in Structure editing.
 In fact, the target
state is taken from, in this sequence, the
REPEAT_TO_STATE property or
org-todo-repeat-to-state. If neither of these is
specified, the target state defaults to the first state of the TODO state
 You can change this using the option
org-log-repeat, or the
will also be prompted for a note.