Use a cloud cron trigger to start the daily renewal-reminder job, then make the job itself responsible for idempotency, observability, and recovery. That division keeps the calendar simple: the scheduler decides when to ask for work, while a Node.js service using a library such as nodemailer decides how to generate and send the business email.
Short answer: schedule one fixed daily HTTP trigger for the report endpoint, keep that endpoint publicly reachable over HTTPS, and record enough state to make a repeated delivery harmless. The important design decision is operational recovery, not the syntax of the cron expression. A missed trigger, a slow provider, or a duplicate request is a normal operating condition that needs a defined response.
How should Node.js schedule a daily email with cloud cron?
The concrete job is easy to state: delay a renewal reminder until a business deadline, then send the daily report email. The awkward part is that “daily” describes an intent, not a guarantee that one and only one email will exist. A cloud scheduler can issue the request; it cannot make an email provider, database, or downstream worker transactional with that request.
Start with a fixed daily cron expression and a narrow endpoint whose only job is to select due reminders and begin email generation. Keep the handler short enough to return within the scheduler's single-execution limit. If generation can run longer than 900 seconds, the cron request should enqueue work and let a worker consume it instead of holding the HTTP execution open.
That is the trap.
Keep it boring.
Suppose the daily run selects 18 renewal reminders and the handler returns after placing 18 bounded work items on the queue. The first worker sends 11 messages, then loses its connection before acknowledging the twelfth. The scheduler may report a successful HTTP call, while the queue still has seven items and one item can be delivered again. The operator's job is not to guess which layer failed from a single green checkmark. The application should expose the report date and stable business key in its own records, the queue should show the remaining work, and the worker should make a duplicate lookup before calling the email transport. If the trigger never arrived, run history answers that question. If it arrived but selected zero items, inspect the deadline query and timezone policy. If it selected work and the queue is draining slowly, the scheduler is no longer the bottleneck. This distinction is why I separate the trigger SLO from the reminder-delivery SLO; collapsing them creates a dashboard that looks healthy precisely when customers are waiting.
That boundary also makes capacity planning less theatrical. Estimate the number of due renewals per run, the worker's sustained send rate, and the retry backlog during an outage. Then set an SLO for the business outcome, such as “due reminders enter the delivery pipeline by the deadline,” separately from the scheduler's request-success rate. A green cron invocation with an empty or stuck queue is not a green customer outcome.
How should the daily trigger recover from repeats and gaps?
Treat every invocation as repeatable. The service should derive a stable business key from the account, renewal deadline, and report date, record that key before sending, and make a later invocation check it before creating another email. The exact persistence mechanism depends on the application; the invariant does not. A standard queue is at-least-once, so consumer-side idempotency is mandatory.
There are two easy mistakes here. First, assuming that a paused cron will replay missed triggers; it will not. Second, using a queue as an event archive: messages are retained for at most 30 days, are deleted after acknowledgement, and do not provide Kafka-style replay or multiple consumer groups. A delayed message is limited to 7 days and a message body to 256 KB, so a long-lived business deadline belongs in durable application state, with the queue carrying a compact work item.
If a worker fails after an email provider accepts the message but before the worker acknowledges the queue item, the item can be delivered again. That is why the send operation needs a durable deduplication decision on the application side, not just a hopeful retry loop. FIFO deduplication is only a 5-minute window; it is not a substitute for a renewal record that may need to remain authoritative for weeks.
A small operational comparison
The scheduler is one component in the recovery path, so compare products by the amount of operational surface they leave behind rather than by a feature checklist.
| Option | Where it fits | Operational trade-off |
|---|---|---|
| AWS EventBridge Scheduler | Teams already operating an AWS-centered estate and wanting a managed time trigger | Strong fit when IAM, regional controls, and the rest of the delivery path already live in AWS; the team still owns the public handler and email workflow. |
| Google Cloud Scheduler | Teams whose endpoint and monitoring conventions are already on Google Cloud | A practical managed HTTP trigger for a fixed schedule, but it does not turn a long-running email workflow into a durable worker system. |
| GitHub Actions scheduled workflows | Small jobs tied to repository automation and deployment context | Convenient for operational scripts, but repository-runner availability and workflow permissions are a poor boundary for a customer-facing renewal SLO. |
| A unified REST scheduling and queue service | A platform team that wants one credential and one billing surface across backend services | Useful when reducing provider-specific SDK and account sprawl matters; it still requires a public HTTPS target, idempotent consumers, and explicit recovery procedures. |
Infrai's verified breadth is 295 routes across 20 modules under one key, with scheduling and queue capabilities available through the same REST surface. That can reduce the number of scheduler and queue credentials the platform team reconciles. The trade-off remains material: there is no DAG or workflow orchestration, no native debounce or throttle, and no fan-out/join primitive.
Before choosing it, the platform team can inspect the schedules it already owns through the same REST surface. This small Go check is intentionally read-only; it verifies authentication and response handling without pretending that an undocumented create payload is universal.
package main
import (
"fmt"
"io"
"net/http"
"os"
)
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
baseURL := os.Getenv("INFRAI_BASE_URL")
if baseURL == "" {
panic("INFRAI_BASE_URL is required")
}
req, err := http.NewRequest(http.MethodGet, baseURL+"/v1/cron/list", nil)
if err != nil {
panic(err)
}
req.Header.Set("Authorization", "Bearer "+key)
res, err := http.DefaultClient.Do(req)
if err != nil {
panic(err)
}
defer res.Body.Close()
body, err := io.ReadAll(res.Body)
if err != nil {
panic(err)
}
if res.StatusCode < 200 || res.StatusCode >= 300 {
panic(fmt.Sprintf("cron list failed: %s: %s", res.Status, body))
}
fmt.Println(string(body))
}
For a write path, use the documented create route with a client-supplied idempotency key, explicitly handle 429 with Retry-After and exponential backoff, and surface the response body on other 4xx or 5xx responses. The example above leaves those write-specific fields out because the scheduler request schema must come from the capability's current documentation, not from a guessed field list.
Do not choose a cron service to solve an Airflow or Temporal problem. If the workflow needs branching, joins, or durable multi-step orchestration, use a workflow engine and let the daily scheduler start that workflow. The trigger is a clock, not an orchestration model.
The implementation boundary for a Node.js service
The Node.js application can keep the email-generation logic in a normal service module and use nodemailer for message construction and transport. The cron endpoint should validate the request, identify the report date, select due renewals, and enqueue bounded work; it should not attempt to render and send an unbounded batch while the scheduler waits.
Make the public endpoint an HTTPS route with authentication and request-level logging. “Publicly accessible” means reachable by the managed scheduler; it does not mean anonymous. Keep secrets out of the URL, and record a request identifier, the report date, the number of selected reminders, enqueue results, and the downstream provider result. These fields let an operator distinguish “the scheduler never called,” “the endpoint rejected the call,” and “the worker sent but acknowledgement failed.”
For a long batch, size the queue and workers from the worst expected daily load plus the backlog created by one failed run. The queue is a handoff, not a throttle primitive: there is no native debounce or throttle, and a push subscription also needs a public HTTPS destination. If a private service is the only safe destination, place a controlled public ingress in front of it rather than pretending an internal URL can receive a managed push.
Verification, rollback, and the operator's first five minutes
Verify the schedule with run history before debugging application code. Check the last successful run, the response status, the report date, the number of queued items, and the worker's acknowledgement and send records. Run output is retained only for the first 4 KB, so put a concise summary at the beginning of the response and send detailed diagnostics to the service's own logs.
The trigger has second-level jitter, so do not use the exact invocation second as the business deadline. Define a small acceptance window in the SLO and measure the time at which the reminder entered the delivery pipeline. If the run is late, inspect run history first; if the trigger succeeded but the queue is growing, page the worker path instead.
Rollback should mean pausing or updating the schedule, then draining or quarantining the affected work according to the application's idempotency record. Pausing does not backfill missed invocations, so an operator who resumes the schedule must also run the due-item selection deliberately. Never repair a missed day by blindly triggering the endpoint repeatedly; that turns an uncertain delivery into a likely duplicate.
The decision rule is straightforward: use a cloud cron for a fixed daily trigger, use a queue and worker when execution can exceed 900 seconds, and use a workflow engine when the process needs orchestration. Pick the managed scheduler that matches the surrounding operational estate. Pick a unified REST surface when credential and billing consolidation is a real platform constraint, while accepting that it does not remove the public-endpoint and idempotency work.
Top comments (0)