What this prompt does
This prompt builds a reliable task scheduling system for a Node.js [framework] app, scheduling the specific [tasks] you list. It combines cron scheduling via [scheduler_lib], a durable task queue on [queue_backend], distributed locking to prevent duplicate execution across [instance_count] instances, retry-with-backoff plus a dead-letter queue, concurrency control capped at [max_concurrent] parallel tasks of the same type, monitoring, graceful shutdown, a manual trigger API, dependency chains, and failure alerts via [alert_channel].
The structure works because naive cron in a multi-instance deployment fires the same job on every node. By requiring distributed locking and a dead-letter queue up front — and tying them to [instance_count] — the output is forced to handle the realities of running scheduled work at scale rather than assuming a single process. The graceful-shutdown and dependency-chain pieces are what make it production-grade instead of a toy scheduler.
When to use it
- When recurring jobs like report emails, cache warmups, or billing runs must fire reliably
- When moving from one instance to
[instance_count]and duplicate cron firing appears - When failed jobs need retries with backoff and a dead-letter queue for inspection
- When some tasks must run strictly sequentially (
[max_concurrent]of one) - When you need a manual trigger API to re-run a job on demand
- When task failures must page someone through
[alert_channel] - When you need an audit of execution history, success rates, and average durations for every scheduled job
Example output
You get a TypeScript implementation: the scheduler wired to [scheduler_lib], queue and worker setup on [queue_backend], the distributed lock mechanism that gates execution across [instance_count] instances, retry and dead-letter configuration, concurrency control capped at [max_concurrent] per task type, admin API endpoints for manual triggers and history, health-check integration, and typed task definitions for your [tasks]. Dependency chains are expressed so one task waits on another, and failure alerts route to [alert_channel]. It includes execution-history and success-rate monitoring rather than just a bare cron registration, so you can see at a glance which jobs are healthy and which are landing in the dead-letter queue.
Pro tips
- Add distributed locking before you scale; once
[instance_count]exceeds one, an unlocked cron runs on every node and double-charges or double-emails - Set
[max_concurrent]to 1 for anything that mutates shared state, like invoice generation, to avoid overlapping runs - Make sure the dead-letter queue is actually inspected — a DLQ nobody reads just hides failures
- Choose
[scheduler_lib]with repeatable jobs (BullMQ) so schedules survive restarts instead of living only in memory - Test graceful shutdown explicitly; in-flight
[tasks]that get killed mid-run on deploy are a common source of partial state - Wire
[alert_channel]to fire on dead-letter arrivals, not just on first failure, so transient retries do not spam the channel
