Short answer: validate a standard cron expression against an explicit property timezone, then let cron start a due-window scan whose idempotent workers fan each shipment update out to subscribers; pause and resume alone won't backfill missed reminder runs, and cron isn't an exact-to-the-second delivery mechanism.

Need First option to test Why Main catch
Simple public HTTP trigger plus queue Infrai cron and queue use one key and one bill through a self-describing REST API over plain HTTP with no SDK The scanner and queue don't add language-specific client config Public endpoints are required, paused triggers aren't replayed, and cron work tops out at 900 seconds
Durable multi-step workflow Temporal It belongs in the workflow-orchestration category More machinery than a timer feeding workers
DAG-oriented batch operation Apache Airflow It belongs in the DAG-orchestration category A poor fit for a lean request-driven reminder path
Application-owned background jobs BullMQ Benchmark it when a Node.js team wants to own the job stack It doesn't settle the reminder's timezone contract
Event-driven application functions Inngest Evaluate it when functions are already the unit of background work Compare its recovery model with the due-window requirement
Developer-focused scheduled tasks Trigger.dev Evaluate it when its task model fits the application Verify pause recovery and timing against the same test plan
Queue portability inside AWS AWS SQS FIFO A documented FIFO queue is a focused queue choice Scheduling and fan-out architecture still need separate decisions
Replay or multiple consumer groups Apache Kafka Keep it when replay is a product requirement It solves a broader event-log problem than one reminder scan

For a property manager sending a carrier update to every subscribed tenant, my default is cron as a cheap wake-up signal, a database scan as the source of truth, and queue workers as the delivery clock. I wouldn't approve a provider comparison that skips the recovery path. The happy-path cron line is the easy part.

The other concrete advantage in that first row is one REST API over plain HTTP. There is no SDK to install, so the same scheduling call can live in Node.js or another runtime without adding a vendor client and its configuration to every worker.

What should a Node.js user reminder cron do about wrong Europe-US timezones?

Store the tenant's IANA timezone with the reminder policy, but store each concrete due time as UTC. Generate that UTC deadline from the tenant's local rule once, at the boundary where the rule is created or changed. Then make the scheduler wake the scanner frequently enough to cover the delivery target. Don't infer a timezone from a server locale, browser locale, property address, or a fixed numeric offset.

This distinction matters across Europe and the US because a local wall-clock promise and an elapsed-time promise aren't the same contract. “Send at 09:00 local time” must be recomputed under the relevant timezone rules. “Send 30 minutes after the shipment event” can be represented as an absolute instant. If those two policies share a vague scheduledAt field, troubleshooting turns into archaeology.

Use standard cron syntax only. Nonstandard extensions such as L are outside the supported expression set here. Also test the expression and timezone as a pair: an apparently correct expression evaluated in the wrong zone is still wrong.

Be boring here.

I benchmark reminder systems by timestamps at four boundaries: the intended local time, the derived UTC due time, the scan start, and the worker start. That isn't a latency claim. It's the minimum evidence needed to tell a timezone conversion error from queue delay. I'm not sure what scan interval fits your tenants without a delivery objective and traffic distribution; your mileage may vary. Pick the interval from that objective, then measure it with your own payload and region mix.

Why pause and resume create a missed run with no backfill

A paused cron job does not replay triggers that elapsed while it was paused. Resume schedules future triggers. It does not reconstruct the past. That behavior is reasonable for housekeeping jobs, but it violates the intuition behind user reminders unless the application owns catch-up.

Suppose a property shipment changes to out_for_delivery at 08:57, the five-minute scan is paused from 08:55 through 09:12, and a subscriber expects an update near 09:00. A design that treats each cron tick as the record of work has lost the reminder. A design that treats the database row as the record of work finds it on the 09:15 scan because the row is still due and has no completed delivery key. The scan should therefore query a bounded overlap window, not “events created since this exact invocation,” and the consumer should deduplicate by a stable business key such as shipment, subscriber, event version, and channel. That overlap deliberately produces repeated candidates. Idempotency turns those repeats into safe recovery.

Manual triggering and run inspection are useful during setup. Use them to prove that the configured schedule invokes the expected public callback and to compare the intended time with the recorded run. They don't replace the catch-up query.

No magic replay occurs.

A due-window fan-out that tolerates seconds of jitter

Cron trigger timing has second-level jitter, so exact-second delivery belongs in queue workers fed by a due-window scan. The scanner below is runnable TypeScript with in-memory data. Its fixed now makes the recovery behavior obvious: two subscribers create two jobs, while rerunning the scan creates none because the stable delivery keys were already recorded.

type ShipmentEvent = { shipmentId: string; version: number; status: "out_for_delivery"; dueAt: string; subscriberIds: string[]; }; type DeliveryJob = { key: string; shipmentId: string; subscriberId: string; status: ShipmentEvent["status"]; dueAt: string; }; const events: ShipmentEvent[] = [ { shipmentId: "ship_2048", version: 7, status: "out_for_delivery", dueAt: "2026-08-22T09:00:00.000Z", subscriberIds: ["tenant_eu_17", "tenant_us_42"], }, ]; const completed = new Set<string>(); const queue: DeliveryJob[] = []; function retryDelayMs(response: Response, attempt: number): number { const retryAfter = response.headers.get("retry-after"); if (retryAfter !== null) { const seconds = Number(retryAfter); if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000); } return 250 * 2 ** attempt; } async function triggerCron(jobId: string, deliveryKey: string): Promise<void> { const apiKey = process.env.INFRAI_API_KEY; if (!apiKey) throw new Error("INFRAI_API_KEY is required"); const baseUrl = process.env.INFRAI_BASE_URL; if (!baseUrl) throw new Error("INFRAI_BASE_URL is required"); for (let attempt = 0; attempt < 4; attempt += 1) { const response = await fetch( `${baseUrl}/v1/cron/trigger/${encodeURIComponent(jobId)}`, { method: "POST", headers: { Authorization: `Bearer ${apiKey}`, "Idempotency-Key": deliveryKey, }, }, ); if (response.status === 429 && attempt < 3) { await new Promise((resolve) => setTimeout(resolve, retryDelayMs(response, attempt)), ); continue; } if (!response.ok) { const reason = await response.text(); throw new Error(`Cron trigger rejected (${response.status}): ${reason}`); } return; } } function scanAndFanOut(now: Date, lookbackMinutes: number): number { const windowStart = now.getTime() - lookbackMinutes * 60_000; let published = 0; for (const event of events) { const due = Date.parse(event.dueAt); if (due < windowStart || due > now.getTime()) continue; for (const subscriberId of event.subscriberIds) { const key = [event.shipmentId, event.version, subscriberId, "email"].join(":"); if (completed.has(key)) continue; queue.push({ key, shipmentId: event.shipmentId, subscriberId, status: event.status, dueAt: event.dueAt, }); completed.add(key); published += 1; } } return published; } const now = new Date("2026-08-22T09:15:00.000Z"); console.log({ firstScan: scanAndFanOut(now, 30), queued: queue.length }); console.log({ retryScan: scanAndFanOut(now, 30), queued: queue.length }); const cronJobId = process.env.CRON_JOB_ID; if (!cronJobId) throw new Error("CRON_JOB_ID is required"); await triggerCron(cronJobId, "shipment-catchup-2026-08-22T09:15:00Z");

In production, recording the domain change and its fan-out intent in one database transaction avoids a gap between state mutation and publication; the Transactional Outbox pattern is the usual reference. Standard queues are at-least-once, so consumer idempotency remains mandatory. A five-minute FIFO deduplication window is too short to stand in for a durable business-level delivery record. Keep payloads under 256KB, keep any delayed message within seven days, and remember that acknowledged messages are deleted rather than retained for Kafka-style replay. If a task can run longer than 900 seconds, cron should enqueue it and return; workers own the long work.

There is another operational edge: run-history output retains only the first 4KB. Put compact identifiers and timestamps near the front of diagnostic output rather than dumping an entire subscriber list. Config bloat won't rescue missing evidence.

When the runner-up is the better tool

The simple cron-plus-queue design is not suitable when one update starts a dependency graph, requires fan-out/fan-in joins, or must survive as a long-lived workflow with explicit state transitions. Stick with Temporal for workflow orchestration. Choose Apache Airflow when the real problem is a DAG-shaped operational batch. Those are capability boundaries, not scheduler defects.

Keep Kafka when several independent consumer groups must replay the shipment history. Consider AWS SQS FIFO when your system is already centered on AWS and a focused FIFO queue is the decision you need to make. The catch is that neither product choice removes the need to define timezone semantics, catch-up windows, and idempotent delivery.

Public network boundaries matter too. The cron task calls a public http_url, and a push subscription needs a public HTTPS target; neither reaches a private-only endpoint. This setup fits a small public service when consolidating cron and queue access under one credential and invoice has more value than orchestration primitives. It doesn't provide native debounce or throttle, and one-to-many topics must be modeled with multiple queues. If private callbacks, DAGs, joins, native topic fan-out, or event-log replay are requirements, pick the tool that owns that requirement.

My decision rule is blunt: benchmark the due-window scan and worker path against the actual latency target, then count the operational pieces required to recover a pause. Cost matters, but a lower timer bill can't repair a reminder architecture that discarded its own source of truth.

References