Make every Node.js SaaS app import emit durable completion evidence, then make uptime monitoring alert on its absence only after the expected delivery window. The deciding constraint is incident reconstruction: a green web health endpoint can prove that the app answers requests, but it cannot prove that yesterday's customer-support import fetched records, committed them, and made them searchable.
Short answer: for a Node.js SaaS app with US and EU users, combine external uptime health checks with a separate cron missed-run detector; record one terminal event for every scheduled import and page only when that evidence is late. Keep enough history to distinguish a late source, a stuck worker, a failed commit, and a broken monitor without guessing. A cheap Healthchecks alternative is still a poor fit if it cannot preserve that incident timeline.
Start with the operational contract
Define success before choosing a monitoring service. For a scheduled support-ticket import, a useful contract names the job, the tenant or source, the scheduled time, the attempt identifier, the start time, the terminal state, the finish time, and the number of results accepted. A completion ping without this context detects silence but leaves the responder unable to reconstruct what happened.
Use two independent signals. An external probe should check a shallow readiness endpoint from the US and EU paths that matter to users. Separately, the import worker should write a terminal event after the durable commit, never merely after fetching a page from the source. Those signals answer different questions, and collapsing them creates an attractive dashboard with a blind spot.
This distinction is small and consequential. Web uptime says the front door opens. Job evidence says the delivery occurred.
Treat the lateness threshold as a capacity-planning input rather than a magic default. An example policy might be deadline = scheduled_at + expected_duration + grace_period, where all three values belong to the job definition and are reviewed when volume changes. The exact duration cannot be inferred from a generic monitoring tool; it must come from the workload's observed distribution and the service objective.
How should a SaaS app monitor Node health and cron runs?
Silence is ambiguous. The scheduler may not have dispatched the job, the worker may have started and stalled, the upstream support system may have delivered no page, the database commit may have failed, or the monitoring event itself may have been lost. A responder needs enough evidence to separate those branches quickly.
No terminal event, no success.
Record state transitions as append-only events, with a stable attempt identifier connecting scheduled, started, and one terminal outcome. Keep result counts as fields rather than encoding them into metric names; Prometheus naming guidance favors a consistent base unit and labels for dimensions, while warning against labels with unbounded cardinality. An attempt ID therefore belongs in logs or traces, not in a time-series label.
Do not equate zero results with a failed run. In customer support, an empty source window may be valid. Alert on the absence of a terminal event, and use a separate policy for an unexpected zero-result streak if the business has a defensible baseline. Otherwise a quiet weekend becomes an incident by configuration.
A practical evidence record can stay vendor-neutral:
package evidence
import (
"context"
"time"
)
type Outcome string
const (
OutcomeSucceeded Outcome = "succeeded"
OutcomeFailed Outcome = "failed"
)
type ImportEvent struct {
Job string
Source string
AttemptID string
ScheduledAt time.Time
StartedAt time.Time
FinishedAt time.Time
Outcome Outcome
ResultCount int64
}
type EvidenceStore interface {
Append(ctx context.Context, event ImportEvent) error
}
The interface is deliberately boring. The hard guarantee belongs at the call site: append succeeded only after the imported records and their checkpoint are durable. On failure, append a sanitized failure class and preserve the detailed error in the system of record. Event-grouping systems commonly derive groups from stack traces or fingerprints; a stable failure class can reduce alert fragmentation without hiding distinct attempts.
Implement the detector outside the app
Run the detector outside the worker's process and, preferably, outside its scheduler. If the same deployment owns the schedule, the work, and the missed-run calculation, one outage can suppress both the job and its alarm. The detector should read schedules and terminal evidence, evaluate overdue instances, and hand a deduplicated incident key to a generic notification interface.
package detector
import "time"
type ExpectedRun struct {
Job string
Source string
ScheduledAt time.Time
Deadline time.Time
}
type TerminalEvent struct {
Job string
Source string
ScheduledAt time.Time
FinishedAt time.Time
}
func IsMissed(now time.Time, run ExpectedRun, event *TerminalEvent) bool {
if now.Before(run.Deadline) {
return false
}
if event == nil {
return true
}
return event.FinishedAt.Before(run.ScheduledAt)
}
That function illustrates the boundary, not a complete scheduler. Production evaluation also needs a declared time zone, daylight-saving behavior, retry semantics, and idempotent incident creation. Store timestamps in UTC, while retaining the schedule definition used to compute the run. A retry should keep the scheduled occurrence stable and receive a new attempt ID; otherwise retries can manufacture apparent extra runs.
Here is the buy-versus-build decision I would put in front of a platform review. It avoids feature-count theater and centers the on-call consequence.
| Decision area | Managed monitor | Self-hosted detector | Gate |
|---|---|---|---|
| Failure isolation | Provider can remain outside the application failure domain | Team must place and operate a separate control plane | Reject any design that can fail silently with the job |
| Reconstruction | Export and retention boundaries may limit terminal evidence | Schema and retention are under team control | Run a timed incident reconstruction before adoption |
| Schedule semantics | Built-in grace and retry rules may constrain the contract | Semantics can match the workload exactly | Document time zones, retries, and late arrivals |
| On-call load | Operations are transferred, but integration still needs ownership | Patching, storage, backups, and detector uptime stay with the team | Include control-plane SLO work in capacity planning |
| Lock-in | Proprietary heartbeat or incident models can raise exit cost | An open event schema improves portability | Prove an evidence export and replay path |
The primary managed-service limitation is control over evidence retention and schedule semantics; the self-hosted limitation is that its control plane becomes another service the team must operate. Price is a constraint, not the decision rule. A free allowance does not compensate for missing history during an incident, and a self-hosted binary is not operationally free once its storage, upgrades, and alerts enter the rotation.
Verify the alarm before trusting it
Test the failure modes, not merely the happy-path ping. In a staging schedule, suppress dispatch and confirm that exactly one missed-run incident opens after the declared deadline. Start a run and hold it before commit; the monitor should still report lateness. Complete an import with zero results; it should be terminal success unless a separate volume policy says otherwise. Finally, block the evidence write and confirm that the detector treats the missing record as uncertainty rather than asserting a fabricated application failure.
Then rehearse the timeline from the stored material. A responder should be able to answer, in order: Which occurrence was expected? Was it dispatched? Which attempts started? Did any attempt commit? When did the detector evaluate it? Which notification was sent? If those questions require querying an engineer's laptop or reading a transient container, the design has failed its reconstruction goal. Keep synthetic health probes equally disciplined: validate status, a small response deadline, and a response field that identifies the deployed service contract, but do not make the endpoint execute the import or perform an expensive dependency tour. Deep dependency checks turn a probe into load and blur ownership; the job detector already owns job completion. This is where SLO language helps. The probe measures availability of the request path, while the missed-run detector measures timely delivery of scheduled data. Give each indicator its own objective and error budget because their users, failure modes, and remediation differ. One blended percentage conceals the very distinction the incident commander needs.
Roll back without erasing the evidence
Deploy detection policy separately from worker code. Start in record-only mode, compare expected runs with terminal events across normal cycles, and inspect late arrivals before enabling paging. When the policy pages too early, roll back the threshold configuration, not the evidence schema and not the underlying history.
Keep the previous detector version and policy available for a bounded rollback window defined by your change process. During rollback, continue accepting events from the worker and tag detector evaluations with their policy version. That preserves the chain of evidence and makes the monitor itself auditable.
The final selection criterion is plain: choose the arrangement that can prove a missed customer-support import, reconstruct its path to failure, and keep raising the alarm when the application stack is unavailable. Everything else belongs below that gate.
Top comments (0)