Short answer: for a small Node.js notification service, poll one delivery-failure metric from a separate scheduled function, evaluate a versioned rule, and send a deduplicated webhook; move to a full incident-management system only when rotations, escalations, and acknowledgement state become requirements.
That answer is deliberately narrower than “install an observability platform.” A logistics team needs to know when delivery notifications stop reaching recipients, but rollback safety changes the shape of the solution: the alert evaluator must not share a deployment fate with the service it watches, and rolling back either component must not replay an old incident or silently reinterpret stored state. The least complex useful design is therefore two small programs with one explicit contract between them.
This isn't a claim that polling wins everywhere. It wins only while the alert surface is small, a few minutes of detection latency is acceptable, and the team already has a trustworthy metrics query endpoint plus a webhook destination.
The delivery-failure ledger comes before the monitor
Start with the symptom the operator can act on. “Process is running” is a weak signal for a notification service; “delivery attempts are failing” is closer to the logistics outcome. The Google SRE monitoring guidance separates latency, traffic, errors, and saturation. Here, errors are the primary signal, traffic supplies the denominator, and latency can be a second rule if delayed delivery is operationally different from failed delivery.
