Skip to main content

8.3.2 Repeated tasks

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 timestamps1. In the following example:

** TODO Pay the rent
   DEADLINE: <2005-10-01 Sat +1m>

the ‘+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’, ‘m’, ‘w’, ‘d’ and ‘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 done once you have done so. When you mark a ‘DEADLINE’ or a ‘SCHEDULED’ with the TODO keyword ‘DONE’, it no longer produces entries in the agenda. The problem with this is, however, is 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 as done, using C-c C-t, it shifts the base date of the repeating timestamp by the repeater interval, and immediately sets the entry state back to TODO2. 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, i.e., org-todo with a numeric prefix argument of ‘-1’.

A timestamp3 is 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 is no longer visible in the agenda when checking past dates, but all future instances will be visible.

With the ‘+1m’ cookie, the date shift is always exactly one month. So if you have not paid the rent for three months, marking this entry DONE still keeps 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 shifts 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 shifts 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 shifts the date to one month after today.

** TODO Wash my hands
   DEADLINE: <2019-04-05 08:00 Sun .+1h>
   Marking this DONE shifts the date to exactly one hour from now.

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 org-agenda-skip-scheduled-if-deadline-is-shown to 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 timestamps.

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.

  1. Org does not repeat inactive timestamps, however. See Timestamps.↩
  2. In fact, the target state is taken from, in this sequence, the ‘REPEAT_TO_STATE’ property, the variable org-todo-repeat-to-state if it is a string, the previous TODO state if org-todo-repeat-to-state is t, or the first state of the TODO state sequence.↩
  3. You can change this using the option org-log-repeat, or the ‘STARTUP’ options ‘logrepeat’, ‘lognoterepeat’, and ‘nologrepeat’. With ‘lognoterepeat’, you will also be prompted for a note.↩