Recurring work in most small businesses is remembered rather than scheduled, which means it is remembered late or by exactly one person. Here is the generator, and the two design decisions that decide whether it is trusted.
Every business has work that happens on a rhythm. Monthly reporting, quarterly reviews, weekly client updates, annual renewals. In most small companies that work is remembered rather than scheduled, which means it is remembered late, or by one person, or not at all.
The obvious fix is a recurring task feature, and most tools have one. The reason to build something slightly better is the horizon.
Why the horizon is the whole design
Native recurring tasks typically appear on the day they are due. That is too late to be useful. The point of knowing about recurring work is being able to plan around it, and you cannot plan around something that materialises the morning it is needed.
Generate too far ahead, though, and the board fills with months of work nobody can start, which is its own failure. People learn to ignore anything with a distant date, and that habit spreads to work that does matter.
Two weeks is the setting I landed on, and it has held up. Far enough to plan a week around, close enough that everything visible is genuinely actionable. Your number may differ, but pick one deliberately rather than accepting whatever the tool defaults to.
Recurring work that appears on its due date is not scheduled work. It is a surprise with a calendar entry.
How to build it
1. Define each series as data
A row per recurring series: what it is, the cadence, the default owner, the lead time, and any client or project it belongs to. Keep it in a sheet or a config table so anyone can add a series without touching code.
2. Run the job daily, not on the cadence
Counterintuitive and important. A weekly job that fails once leaves a two-week hole nobody notices until something is late. A daily job that looks at a rolling window recovers by itself the next morning.
3. Make it idempotent
Before creating anything, check whether an item already exists for that series and that due date. Without this check, one duplicate run produces two of everything and people stop trusting the board immediately. This is the single most important line of code in the automation.
4. Tag generated items so you can find them
A label or field marking the series it came from. You will need this to clean up after a mistake, to report on completion rates, and to retire a series without hunting.
5. Handle the calendar realities
Month ends, holidays, and the difference between the last Friday and the last day. Decide explicitly what happens when a due date lands on a non-working day rather than discovering it in December.
6. Watch your execution quotas
Google Apps Script allows six minutes per execution and caps daily trigger runtime. A daily job over a two-week window is comfortably inside that, but batch your reads rather than looping row by row, which is what causes most timeouts.
Tools and what they cost
| Option | What it costs | Honest trade-off |
|---|---|---|
| Native recurring tasks in your tracker | Included. | Zero effort. Usually appear on the due date rather than ahead, and often cannot carry a full template of subtasks. |
| Jira automation with a scheduled trigger | Included but capped: 100 executions a month on Free, 1,700 pooled on Standard. | Fine for a handful of series. A daily job across many series consumes the allowance quickly. |
| Apps Script on a time-driven trigger | Free with Google Workspace. | Full control of the horizon and the idempotency check. Mind the six minute limit and daily trigger runtime quota. |
| Connector platform with a scheduler | Billed per task or operation, and a daily job across many series multiplies fast. | Quick to build. The pricing model penalises exactly the daily-run pattern that makes this reliable. |
What it is actually worth
The saving is not really time, and I would be stretching to claim otherwise. Creating a recurring ticket takes a minute.
The value is in what stops happening. Recurring work that gets missed entirely, or that gets done in a rush because it appeared that morning, or that only one person remembers. That last one is the real exposure: a recurring obligation held in someone's memory is a continuity risk, and it becomes visible the week they are on leave.
Measure it this way: count the recurring obligations in your business that currently exist only as somebody's memory or a personal calendar reminder. That count is what this automation converts into institutional knowledge. It is a more honest measure than hours saved, and a more compelling one to a founder.
How it breaks
Duplicates. The most common failure by a distance, and almost always caused by a missing idempotency check or a job that was manually re-run after an error. Build the check first.
The series list goes stale. A client leaves and their weekly report keeps generating for months. Review the series list quarterly, and make retiring a series as easy as adding one.
Generated work is ignored because it is generated. If people treat automated tickets as less real than ones a human created, the whole thing fails quietly. Assign a named owner at generation rather than leaving items unassigned; unassigned generated work is what teaches people to ignore it.
The job fails silently. Same rule as every scheduled automation: it must report its own errors somewhere a person reads.
How to tell whether it worked
Three measures. Recurring obligations missed or completed late, which should approach zero. The number of recurring items completed by someone other than the usual owner, which tells you the knowledge left one person's head. And whether the recurring work ran correctly during somebody's annual leave, which is the only test that really matters.