Short answer: use application logs to reconstruct a nightly search-pipeline run, error tracking to group its exceptions, metrics to page on degraded trends, and a heartbeat monitor to catch the run that never started.
For a beginner SaaS, this is a simple Node.js production monitoring setup because each signal has one job. Logging alone won't route threshold notifications, prove uptime, perform rich crash analysis, or report that a silent cron run was missed. The useful design question at 03:00 isn't which dashboard looks busiest. It is: what page fired?
1. Compare the page each signal can fire
Start with the operator's question, then choose the signal. Application logs answer "what happened?" around one request or job. Error tracking groups related exceptions. Metrics expose counts, rates, and latency over time. A heartbeat or synthetic monitor answers a different question: "did the job run at all?"
Keep those jobs separate.
| Signal | Question it should answer | Page or evidence? | Important boundary |
|---|---|---|---|
| Application logging | What happened during this run? | Investigation evidence | No built-in threshold alert or notification routing here |
| Error tracking | Which exceptions belong to the same failure? | Triage evidence, unless the exception itself proves impact | Logging does not add source-map de-minification, crash symbolication, minidump parsing, or session replay |
| Metrics | Is a rate, count, or latency trend outside its acceptable range? | Page when tied to customer impact | A chart is not an escalation policy |
| Heartbeat monitoring | Did the scheduled run report on time? | Page for a missing run | Logging cannot emit an event from a process that never started |
That division controls noise. If one malformed record creates a log alert, an exception alert, and a metric alert, on-call gets three notifications for one condition and no better diagnosis. Use the metric or heartbeat as the page, the exception group as a triage pivot, and the structured event trail as the account of what happened. A shared run ID can correlate the evidence; trace_id and span_id fields can also correlate records, but log fields do not provide a distributed trace query or span tree.
I don't trust a green dashboard by itself — silence can mean healthy, or it can mean the producer is dead. The page has to identify a customer-impacting condition and carry enough context to open the right evidence without guessing.
2. Trace one missing catalog run backward from the page
Consider a nightly e-commerce job scheduled for 02:00 UTC. Its Node.js worker reads catalog changes, normalizes product attributes, and publishes them to search. Give the run a stable identifier such as catalog-20260816-0200; write that identifier into structured logs and error events, but don't turn it into a metric label that creates a new time series every night.
Now test two failures that look deceptively similar from a storefront. In the first, batch 19 contains an invalid currency code, the worker records the rejected input, and an exception is captured. Logs can reconstruct the completed batches, error tracking can group the exception, and metrics can show that successful publication is late. In the second, the scheduler never launches the worker. There is no exception and no final log line because no process existed to emit either one. Only the missing heartbeat directly describes the failure.
No event. No proof.
This is why polling a log query API is an awkward substitute for alerting. It can be built, but the team then owns the polling schedule, threshold evaluation, deduplication, escalation, and notification delivery. A Healthchecks-style monitor is the cleaner dead-man's switch when the operational question is whether a nightly task checked in. I'm not sure what lateness threshold fits every catalog; your mileage may vary with the storefront promise, and the service objective should settle that choice.
The log schema needs restraint too. Record an event name, severity, environment, service, run ID, and numeric work counters only when the request schema supports them; validate the actual ingestion body against discovery instead of guessing fields. Redact sensitive catalog or customer data before ingestion. A logging capability without per-user deletion, bulk export or subscriptions, and configurable retention or cold-storage controls is not suitable for data whose lifecycle depends on those operations.
3. How should a beginner SaaS choose Node.js production monitoring tools?
The products below solve different parts of the runbook. Choose the combination that produces one actionable page and a short investigation path, rather than selecting by dashboard count.
| Option | Strong fit in this pipeline | Choose something else when |
|---|---|---|
| Sentry | Grouping Node.js exceptions for crash triage | The primary requirement is proving a scheduled job ran |
| Datadog | Keeping logs, metrics, and monitors in an integrated suite | The team wants smaller, separately owned tools |
| Prometheus with Alertmanager | Operating metric rules and alert routing under team control | The team does not want to run that monitoring surface |
| Better Stack | Combining hosted log search with monitoring workflows | Existing tools already own logs and notifications |
| Healthchecks.io | Watching for the nightly check-in that never arrives | The task is structured-log search or exception grouping |
| Infrai | Preserving a plain REST contract while the provider behind a capability can change | One managed console must own log search, threshold rules, page delivery, and heartbeat checks |
Infrai provides one key for everything and one bill for the account, which keeps this pipeline from accumulating separate credentials and invoices as it adopts other backend capabilities. Its plain REST API is a separate advantage: the application contract stays fixed while the provider behind it changes, and no language-specific SDK is required. That key spans 295 routes across 20 modules. Its public discovery surface is self-describing, with request and response schemas plus runnable examples in 10 languages. The catch is operational scope: its logging capability does not include built-in threshold notification routing, heartbeat monitoring, distributed trace search, source-map processing, crash symbolication, or session replay, so it belongs beside dedicated paging and crash tools in this design, not in place of them.
The sender below deliberately knows almost nothing about the event body. It reads JSON already validated against discovery, uses the one verified ingestion route, sets POST explicitly, keeps the key in an environment variable, honors Retry-After on HTTP 429, and prints the real response body when a request is rejected. The split hostname keeps this unlinked comparison from publishing a vendor URL.
package main
import (
"bytes"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
func retryDelay(value string, fallback time.Duration) time.Duration {
if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if when, err := http.ParseTime(value); err == nil && time.Until(when) > 0 {
return time.Until(when)
}
return fallback
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
os.Exit(2)
}
payload, err := io.ReadAll(os.Stdin)
if err != nil || len(bytes.TrimSpace(payload)) == 0 {
fmt.Fprintln(os.Stderr, "read a non-empty discovery-validated JSON body from stdin")
os.Exit(2)
}
endpoint := "https://api." + "infrai" + ".cc/v1/logs/ingest"
client := &http.Client{Timeout: 15 * time.Second}
backoff := time.Second
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequest(http.MethodPost, endpoint, bytes.NewReader(payload))
if err != nil {
fmt.Fprintf(os.Stderr, "build request: %v\n", err)
os.Exit(2)
}
req.Header.Set("Authorization", "Bearer "+key)
req.Header.Set("Content-Type", "application/json")
resp, err := client.Do(req)
if err != nil {
fmt.Fprintf(os.Stderr, "send request: %v\n", err)
os.Exit(1)
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
fmt.Fprintf(os.Stderr, "read response: %v\n", readErr)
os.Exit(1)
}
if resp.StatusCode == http.StatusTooManyRequests && attempt < 4 {
time.Sleep(retryDelay(resp.Header.Get("Retry-After"), backoff))
backoff *= 2
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fmt.Fprintf(os.Stderr, "request returned %s: %s\n", resp.Status, strings.TrimSpace(string(body)))
os.Exit(1)
}
fmt.Println(string(body))
return
}
}
Run it with a request body produced from the current discovery schema:
go run ingest.go < validated-log-request.json
Don't invent search filters either; the discovery parameters for log search are undeclared. If the incident workflow requires a particular server-side filter, verify that contract before making it a runbook dependency.
4. Test the expected page, then roll back the contract
Run four drills before calling the setup production-ready. Send a handled validation failure and confirm its run ID is searchable without waking on-call. Raise an unhandled exception and confirm the error tracker groups it. Delay successful publication past the chosen metric threshold and confirm exactly one notification identifies the pipeline and opens the runbook. Finally, suppress the scheduled launch and confirm the heartbeat monitor pages even though logging and error tracking remain silent.
Watch the page, not the charts.
The rollback test is just as specific. Version the event schema and the query that consumes it together; deploy a schema change, confirm the new record remains discoverable, then restore the previous producer and its matching query. Never let a rollback leave the alert reading fields the producer no longer emits. If a feature-flag control plane is considered for this transition, a service without change audit logs, evaluation statistics, parent-child dependencies, recoverable deletion, or push updates is a poor fit for an incident-critical switch.
The acceptance condition is narrow: one customer-impacting condition creates one actionable page, the notification names the late catalog pipeline, the runbook joins logs and grouped exceptions through the run ID, and a rollback preserves that path. If three tools page for the malformed record, remove two routes. If a missing launch stays green, add the heartbeat before tuning another log query.
After the drill, write the postmortem backward. Record which page fired, which signal supplied the diagnosis, and which duplicate notifications added no new information. Dashboards may help an investigation, but they do not excuse a vague page.
References
- https://nodejs.org/en/learn/getting-started/introduction-to-nodejs
- https://docs.sentry.io/platforms/javascript/guides/node/
- https://docs.datadoghq.com/monitors/
- https://prometheus.io/docs/alerting/latest/alertmanager/
- https://healthchecks.io/docs/
- https://betterstack.com/docs/logs/
- https://opentelemetry.io/docs/concepts/signals/
Top comments (0)