How to Track Small Repeated Tasks Without Creating Hundreds of Useless Cards

We used to make a new task every Monday for "check the client backups." Simple enough. Four months in, we had sixty-some cards named almost the same thing, most of them untouched after the day they were created, and when an actual audit asked us to show a history of the checks, we spent an afternoon scrolling instead of five minutes pulling a list.

The problem wasn't that we were tracking too much. It was that we'd picked the wrong shape for what we needed to remember. A task card is built to hold a title, a status, maybe a description and some discussion. A weekly check that almost never produces anything worth discussing doesn't need any of that. It needs a box and a date.

The question isn't how often. It's what you need to remember.

Teams usually sort recurring work by frequency — daily, weekly, monthly — and then pick one tool for all of it. That's backwards. Frequency tells you nothing about the record you need afterward. Two tasks that both happen weekly can need completely different homes.

"Water the office plants" and "submit the weekly compliance filing" are both weekly. One needs a checkmark. The other needs a timestamp, a name attached to it, and sometimes a note about what was filed and where. If you track both the same way, you either bury the filing in noise or you build ceremony around the plants.

The actual question is: when this occurrence is done, what do you need to be able to answer later? Did it happen at all? Who did it and when? Did anything unusual come up that someone needs to see? The honest answer sorts the work into one of a few shapes, and each shape has a natural home.

The one-line repeat: a recurring task with nothing attached

Some repeated work only needs a yes or no. Restocking a shared supply, confirming a backup ran, locking up on a rotation — the thing either happened or it didn't, and nobody is going back to read notes about it next quarter.

This is what a recurring task addon is for in Team and Tricks: a task that comes back on its own schedule instead of you recreating it by hand every week. You don't manage sixty copies of the same card. You manage one commitment that resurfaces when it's due. If it never needs a description, a due-date warning, or anyone assigned beyond the one person on rotation, don't add those things. A bare recurring task is still a complete task.

If the thing you're checking is really a short list of sub-items — close the register, wipe the counters, set the alarm — that's a checklist task, not five separate recurring tasks. One task, several rows, each row checkable on its own. You get the granularity without the duplication.

The repeat that occasionally turns into real work

Most onboarding steps are routine. Every so often one isn't — a client's contract needs a non-standard clause, a vendor setup hits a permissions wall, a row that was supposed to take five minutes needs a person, a thread, and two days.

This is the case teams get wrong most often, in both directions. Make every row its own task up front and you've built ceremony around work that's usually trivial. Leave everything as a checklist row forever and the one occurrence that actually needs ownership, a due date, and a discussion gets squeezed into a comment thread on a line item that was never meant to hold it.

The checklist task type exists for exactly this gap. Rows carry their own priority, their own assignee, their own comment thread, and an attention marker — Question, Attention, Blocked — so the one row that's actually stuck is visible without inflating the other nineteen. And when a row genuinely grows into real work, it can be promoted into its own task. You don't decide the shape of the work in advance for every occurrence. You decide it when the occurrence tells you it's different.

The repeat that needs a trail, not a project

Some recurring work isn't really a task at all once it's done — it's a record. A weekly safety walk-through, a monthly reconciliation, anything where the point is proving later that it happened and who was responsible. You don't need a live card sitting in a board for that. You need something that survives after the occurrence closes.

Here the mistake is treating the record like active work. A card that's been done for six weeks doesn't need to keep occupying a column titled "In Progress." Let the recurring task resurface, get closed, and let whatever evidence matters — a note, a file, a progress report — live attached to that instance or in a document scoped to the project. The current occurrence is work. The history of past occurrences is a document, not a backlog you have to keep clean.

What not to reach for

We tried, at different points, to solve this with more structure instead of a better match. A spreadsheet tab per recurring item. A master checklist that tried to hold the daily plant-watering and the quarterly audit on the same page. A folder of "template" tasks we duplicated by hand every time, which is the sixty-cards problem with extra steps.

Sometimes a spreadsheet really is enough — if the only thing you need is a column of dates with a checkmark next to each, don't build a workflow around it. But the moment a repeated item sometimes needs a person assigned, sometimes needs a conversation, and sometimes needs nothing at all, a spreadsheet can't flex between those without someone manually deciding, each time, where this occurrence belongs. That decision is exactly what a checklist row with an attention marker, or a task that can be promoted, is built to carry.

• Needs only a yes or no, nothing to remember after → a recurring task, no addons beyond the recurrence itself
• Several short sub-steps per occurrence, same frequency → one checklist task with several rows
• Usually routine, occasionally real work with its own owner and timeline → checklist row, promoted to a task only when it earns it
• Needs a durable trail more than active tracking → close the occurrence, keep the record in a document, not a stale card

None of this is about frequency. A thing that happens once a year and a thing that happens every morning can need the exact same shape, if what you need to remember about them is the same. The sixty cards we made weren't wrong because we checked the backups every week. They were wrong because a yes-or-no check doesn't need a project card's worth of structure, and we never stopped to ask what we'd actually need to look up later.