Here is a number worth sitting with. In one live system, a single user's generated action queue had grown from 389 open items to 541, then to 583. It then sat at 583, unchanged, for nineteen days. Every reminder digest sent during that period was unopened.

Nothing was broken. No bug, no outage, no integration failure. The system worked exactly as it was designed to work. It had simply been generating obligations for longer than any human could absorb them, and the person on the receiving end had done the only rational thing available to them: stopped looking.

This is not a story about one badly configured tool. It is the resting state of an entire category of software, and it is worth understanding the mechanism before you evaluate another one.

The arithmetic nobody runs before buying

Tools that generate work — recurring tasks, reminders, nudges, alerts, weekly digests — are sold on a compelling premise: the system will keep everyone honest. Nothing will be forgotten, because the software will not let it be forgotten.

The mechanism underneath that premise is simpler and less flattering. The system manufactures items and assumes a human clears them. That assumption has an arithmetic problem: the generator runs on a schedule and the human runs on available attention. One of those is constant and the other is not. In any week where the work gets heavier — which is to say, in any week that matters — generation continues at full rate while clearing drops toward zero.

The gap does not close later. Attention that was not available last Tuesday does not become available this Tuesday with interest. So the queue grows, monotonically, and the only question is how long it takes to cross the threshold at which it stops being readable in a sitting.

Once it crosses, behaviour changes discontinuously. A queue of forty items is a to-do list. A queue of four hundred is a wall. People do not work through walls; they route around them. The reasonable response to an unreadable queue is to stop opening it, and that is what people do.

What happens after abandonment

The interesting part is what the tool does next, because it does not go quiet. It keeps generating. It keeps sending digests. The dashboard keeps reporting an open-item count that climbs.

From the outside, the system now looks busier than ever. Someone reviewing it sees activity, volume, engagement metrics. What they are actually looking at is the tool talking to itself. The generated items are no longer descriptions of work anyone intends to do; they are artefacts of a scheduler. The tool has stopped reporting on the work and started reporting on its own output.

This is the failure that makes the whole thing expensive rather than merely useless. A tool nobody opens is a wasted subscription. A tool nobody opens that still produces confident-looking numbers is a source of decisions made on fiction.

The tell is movement, not size

If you want to know whether this has happened in your own stack, do not look at the size of the queue. Size on its own is ambiguous — a large queue that is being actively worked is a sign of a busy team, not a broken system.

Look at three things together, and it takes about four minutes:

  • The trend. Has the open count moved in the last three weeks? An unchanging number is not stability. It is the signature of a queue that nobody is touching in either direction.
  • The age of the oldest item. If the oldest open item predates the last two quarters, the queue is not a backlog. It is an archive that nobody has admitted is an archive.
  • Digest engagement. Were the last four reminder emails opened? This is the one people skip, and it is the most diagnostic. Unread digests alongside a static count is abandonment, not diligence.

In the case above, all three pointed the same way: 583 items, unchanged for nineteen days, digests unopened. Any one of those alone might have had an innocent explanation. Together they described a system that had been quietly switched off by its user without anyone cancelling the subscription.

Why "just clear the backlog" does not work

The instinctive fix is a clean-up. Declare backlog bankruptcy, bulk-close everything older than a date, start fresh with better discipline.

This works for about six weeks. It has to, because the generator was never the thing that changed. Whatever rate of manufacture produced 583 items the first time will produce them again, and the second abandonment happens faster than the first because everyone now knows how the story ends.

The more useful question is not how to clear the backlog. It is whether a backlog should have been possible at all.

A record that cannot outrun its reader

There is a design that does not have this failure mode, and it is almost embarrassingly simple: let nothing add a row automatically.

In a record where only a person writes an entry, accumulation is impossible by construction. There is no generator, so there is no rate to outpace. A day on which nobody wrote anything is not an unfinished item sitting in a queue — it is simply a day on which nobody worked on that thing, which is a fact rather than an obligation.

That single decision changes what every downstream number means. Instead of an open-item count that reflects the scheduler's productivity, you get a straightforward measure: days recorded divided by working days, with the denominator coming from each person's schedule and the organisation's holiday calendar. That number is honest, cheap to produce, comparable across people on different schedules, and — crucially — it cannot be inflated by the system quietly adding rows.

It also has a property the generated queue never had: it degrades visibly. If people stop writing, the compliance figure falls immediately and obviously. There is no version of this where the numbers look healthy while everyone has stopped participating, because the numbers are made of participation.

What to check before you buy the next one

When you evaluate a work tracking tool, the feature list will not tell you whether it has this problem. Ask three questions instead:

  • Does anything create items without a person doing it? If yes, you have a generator, and generators accumulate.
  • What does a day with no activity look like? If it becomes an item, you are building a backlog. If it stays empty, you are building a measurement.
  • Can the reporting look healthy while nobody is using it? If the answer is yes, the reporting is about the tool rather than about your company.

None of those is about features. All three are about whether the thing you are buying can end up at 583, unchanged, for nineteen days — while still sending you a weekly summary that nobody opens.

GoWarm Work generates nothing. A person writes one line about what they did, it is stored once, and a day with no entry stays blank. That is a smaller claim than most tools make, and it is the reason the record is still readable in month six.