Short answer

Leave it blank by default. The recurrence rolls forward indefinitely and the system extends the task window automatically — you don't need to "give it a stop date" for it to keep running. Only set an end date when the routine is genuinely time-bounded (a temporary project) or seasonal (a different frequency in summer vs winter).

Detail

A common first-time mistake is to set the end date to something far in the future — two years out, five years out — under the assumption that the routine needs a stop date to know how long to run. It doesn't. The recurrence is treated as "forever" by default; the system materialises the next batch of subtask instances as time progresses, so you always have enough scheduled work in view without pre-generating thousands of rows.

The cost of setting a far-future end date isn't conceptual, it's volumetric: the system rolls all of those occurrences forward as parent and subtask rows, which clutters the task list, makes the database row count blow up, and obscures the actual operational view of "what's coming this week". One council we worked with set the end date to 2028 on a daily routine and ended up with 2,180 task rows for what should have been a couple of hundred.

When to actually set an end date:

  • Temporary work — a routine that's genuinely scoped to a fixed window (e.g. a contract pilot that runs for 12 weeks, a one-off project).
  • Seasonal patterns — a routine that only runs in certain months of the year (e.g. monthly grass cutting Nov–Mar, weekly bin emptying that increases frequency in summer). In that case, set the due date and recurrence end date to the season boundaries and tick Repeat every year so it picks itself up again next season. See How do I model a recurrence that only runs in certain months (e.g. November to March)?.

How to clear an end date that's already set: open the routine → clear the recurrence end-date field → Update → "update all future occurrences". Worth verifying the system properly retracts the over-rolled subtasks after the change — historically the cleared-end-date behaviour hasn't been heavily tested in production.

Watch-outs

  • Don't set an end date "just in case" — that's the classic over-generation trap. Default to blank.
  • Routines pre-roll a future window of subtasks for visibility, not for storage. A daily routine will show several months of upcoming jobs at any given time, even with a blank end date. That's expected.
  • If you do want to model a seasonal pattern, an end date is required — that's how the engine knows the window to repeat each year. But pair it with Repeat every year so it actually re-applies.