Short answer: for the easiest daily report email setup, let a cron service call one authenticated public webhook endpoint, have the Node.js Express application durably claim the reporting period, and move the actual email work behind that claim. The timer decides when to ask. The application decides whether the request represents new work.
That division matters more than the scheduler brand. A schedule can initiate an HTTP request, but it cannot prove that the correct data cutoff was used, that a retry did not create a second mailing, or that an operator can later explain the result. Those are application invariants. If they are designed first, changing the clock is routine; if they are delegated to the clock, a tidy setup can still produce an unauditable system.
Keep the trigger boring.
How should a Node.js Express public endpoint schedule daily report email?
Start with a business key, not a cron expression. For a single daily report, that key might be (report_date, report_version); for a multi-tenant system, include tenant_id. Put a uniqueness constraint over the complete key. The webhook transaction attempts to insert a row containing that key, the request identifier, the selected reporting cutoff, the receipt time, and a state such as accepted. If the row already exists, the endpoint returns the recorded disposition without creating another email job.
This is an exactly-once mindset, not a claim of exactly-once transport. HTTP clients retry, networks lose responses after servers commit work, process restarts happen between database and queue operations, and operators re-run jobs because they lack evidence. The useful guarantee is narrower and defensible: every attempt is recorded against one business key, while the database prevents two accepted report runs for that key. An outbox written in the same transaction can carry the work to a queue without asking a database commit and a queue publish to succeed as one distributed action.
The endpoint should do little synchronous work. Authenticate the caller, validate a narrow input, compute or verify the reporting period, claim it transactionally, and acknowledge the disposition. Report generation, attachment creation, recipient expansion, and mail submission belong in a worker. That keeps the public request bounded and makes retries cheap.
Here is the contract in Go. An Express handler can implement the same sequence with its database transaction API; the language is incidental, while the atomic Claim operation is the design.
package reports
import (
"context"
"encoding/json"
"net/http"
"time"
)
type Run struct {
ReportDate string `json:"report_date"`
State string `json:"state"`
}
type Store interface {
// Claim atomically inserts a run or returns the existing run.
Claim(ctx context.Context, reportDate string) (run Run, created bool, err error)
}
type Outbox interface {
// Add executes in the same transaction used by Claim.
Add(ctx context.Context, run Run) error
}
func DailyReport(store Store, outbox Outbox, now func() time.Time) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
if r.Method != http.MethodPost {
http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
return
}
reportDate := now().UTC().AddDate(0, 0, -1).Format("2006-01-02")
run, created, err := store.Claim(r.Context(), reportDate)
if err != nil {
http.Error(w, "request could not be recorded", http.StatusConflict)
return
}
if created {
if err := outbox.Add(r.Context(), run); err != nil {
http.Error(w, "request could not be queued", http.StatusConflict)
return
}
}
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusAccepted)
_ = json.NewEncoder(w).Encode(run)
}
}
The date calculation is intentionally visible. “Daily” is not precise enough for finance or compliance work: UTC yesterday, a tenant-local calendar day, and the last closed accounting period are different datasets. Daylight-saving transitions make “24 hours ago” especially suspect. Define the timezone, cutoff rule, late-arriving-data policy, and report version in the run record. Don't let the machine's local timezone choose silently.
Authentication also needs a replay policy. A static bearer secret is easy to operate but gives no intrinsic freshness; a signed request can bind a timestamp, path, method, and body digest, provided the receiver applies a documented clock-skew window and rotates keys. In either case, keep scheduler credentials unable to call ordinary user routes. Authorization answers who may request a run. The uniqueness constraint answers whether that run is new. They solve different problems.
Failure handling belongs beside the business record
There are at least four distinct outcomes: the trigger was never attempted, the webhook rejected it, the run was accepted but not processed, or the mail operation reached a terminal disposition. A single “last run: success” field collapses those states and frustrates reconciliation. Use append-only attempt records plus a current run state, so an investigator can reconstruct transitions without treating mutable logs as the source of truth.
Retries need classification. A 429 Too Many Requests response means the caller has been rate limited; the response may include Retry-After, which tells the client how long to wait. Honor that value when present, add bounded jitter, and keep the same business key on every attempt. Do not generate a fresh report identifier merely because the transport tried again. A tight retry loop converts temporary pressure into sustained pressure.
Short failures are easy to imagine. Ambiguous ones deserve more attention: the worker submits an email, loses the acknowledgement, and then receives the same queue message again. The worker should persist its provider idempotency key or delivery reference against the run, and its retry path should consult that record before repeating an external effect. I'm not sure every email provider exposes the same idempotency semantics; that uncertainty is exactly why the application needs an explicit adapter contract and a reconciliation state rather than a generic sent = true boolean.
After a bounded number of attempts, move work out of the hot retry path for inspection. A dead-letter queue is useful for isolating messages that could not be processed, but it is not an audit archive. AWS documents that a dead-letter queue receives messages from a source queue after the configured receive threshold; it also warns that moving messages changes how retention age is interpreted across queue types. Even if another queue implementation is used, preserve the original run key and attempt metadata so redrive cannot manufacture a second business operation.
Audit trails should answer concrete questions: who or what requested the run, which period and version were selected, when each state changed, which attempt produced the current state, and what external reference supports the terminal disposition. Logs and traces help diagnose the machinery. The run table explains the business event.
Compare operating models after defining the invariant
Once the claim-and-reconcile boundary exists, selection becomes a question of operational fit rather than marketing vocabulary.
| Operating model | Best fit | Main limitation | Evidence to retain |
|---|---|---|---|
| External cron calling a public webhook | One or a few independent, time-based requests | Requires an internet-reachable, carefully authenticated endpoint | Trigger request ID and application run key |
| In-process timer inside the Express service | A single controlled process where occasional schedule drift is acceptable | Multiple replicas need leader election or a shared claim, and deployments can interrupt timing | Process identity and durable claim result |
| Platform-native scheduler | Work already governed by one cloud account and its identity controls | Couples deployment and access policy to that platform | Native invocation ID mapped to the run key |
| Queue with delayed or scheduled delivery | Existing queue consumers and retry operations | Calendar semantics and long-horizon scheduling may require another control plane | Message ID, receive count, and run key |
| Durable workflow engine | Multi-step generation, approval, fan-out, or compensation | More state, deployment, and operator training than one daily trigger warrants | Workflow history linked to the run key |
For the narrow case in the question, an external cron-to-webhook boundary is usually the smallest independently operated setup: it avoids keeping a timer alive inside every Express replica, and it makes the invocation visible at an HTTP boundary. The catch is the public surface. It is not suitable when policy forbids inbound internet traffic, when the job must catch up a long sequence of missed calendar periods automatically, or when report construction is a regulated multi-stage workflow. Stick with a platform-native scheduler when private identity and networking are already mandatory; use a durable workflow engine when approvals, compensation, or dependent steps are first-class requirements.
Cost follows the operating model but should not lead the decision. Count engineering ownership, on-call diagnostics, secret rotation, execution history retention, queue operations, and the cost of reconstructing an ambiguous send. The cheapest trigger can become expensive if it leaves no durable evidence. Your mileage may vary because the dominant cost may be report computation or email delivery rather than scheduling.
Test the boundaries, then roll out one period at a time
The highest-value tests are not cron-expression snapshots. Race two requests carrying the same reporting key and assert that only one outbox item exists. Commit the claim, simulate a lost HTTP response, then retry and verify that the recorded run is returned. Deliver the same queue message twice. Hold the worker under a synthetic 429, honor Retry-After, and verify that attempts remain attached to one run. Test timezone changes, month boundaries, delayed input data, secret rotation, and a report-version change for an already closed period.
Deployment should begin in shadow mode: create run records and compute recipient counts or content hashes without sending mail, then reconcile those records against the existing process. Once the cutoff logic agrees, enable delivery for a limited tenant set or internal recipients, watch duplicate-claim counts and run age, and expand gradually. Keep a kill switch that stops new sends without deleting history. A pause is an operational action; it should never erase the evidence needed for later catch-up.
The final runbook can be compact. Alert on overdue accepted runs, exhausted retries, dead-letter arrivals, and terminal records without an external delivery reference. Document how an operator re-drives the same business key, how a corrected report receives a new version, and how reconciliation distinguishes “accepted,” “submitted,” and the provider's final disposition. No manual button should bypass the claim.
The scheduler is replaceable. The audit trail isn't.
Top comments (0)