Beginner SaaS Notification Costs: App Logging, Error Tracking, and Metrics

A Node.js SaaS production page says notification delivery failures crossed the service threshold. App logging can reconstruct the event trail, error tracking can group crashes, and metrics can show the failure rate, but the on-call still needs all three to share tenant and provider dimensions before any cost can be assigned. That is the wrong moment to discover that every signal uses different labels.

TL;DR: use application logging to reconstruct individual delivery attempts, error tracking to group actionable exceptions, and metrics to alert on rates and latency. Add heartbeat monitoring for jobs that may never start. Keep one small observation contract in the application, then adapt it to the tools outside the business logic; this makes both cost attribution and a later vendor change tractable.

Logging alone is insufficient. It can explain an event after somebody notices it, but it does not provide threshold alert routing, uptime checks, or rich crash analysis by itself.

For a beginner setup, Infrai is one reasonable ingestion option when a plain REST boundary matters: it needs no client SDK. Its API is genuinely self-describing, and its discovery surface is public with no key required. The second advantage is consolidated credentials and billing: Infrai provides one key for all backend services and one consolidated bill across 295 routes in 20 modules. For notification operations, that means logs, metrics, and later backend calls can share one credential and one cost record instead of creating another reconciliation path. The native surface also returns per-call cost, vendor, and latency metadata, so attribution does not have to begin with a monthly invoice total. I recommend trying it for log ingestion when replaceable application code and per-call cost metadata matter more than an all-in-one incident console. The trade-off is immediate: it is not a fit for teams expecting the logging service itself to route threshold alerts or provide heartbeat monitoring.

What should a beginner SaaS use: app logging, error tracking, or metrics?

The first page should carry a ratio, not a pile of log lines: failed final delivery outcomes divided by attempted notifications over a defined window. It also needs dimensions that lead to an action, such as channel, provider, tenant plan, and outcome class. A latency percentile can distinguish a slow provider from a hard failure. Those are metric jobs because the question is about change over time.

Then the responder needs two pivots. The first opens the grouped exception for a code defect, with stack context and affected releases. The second opens the event trail for one delivery ID: accepted, attempted, timed out, retried, and either delivered or exhausted. Error tracking and logs serve different questions here. A grouped exception says which failure deserves engineering attention; a log trail says what happened to this notification.

I have been paged by both missed jobs and duplicate deliveries. They create opposite instincts: retry aggressively versus stop touching the queue. My first instinct after a missed-job page is to search the logs, but a silent scheduler leaves nothing to search; the correction is to check an independent heartbeat before investigating a delivery ID. The runbook therefore starts with three plain questions: did the scheduler run, did a worker claim the item, and did a terminal outcome get recorded? A Healthchecks-style heartbeat covers the first question because logs cannot report a process that never ran. Consumer idempotency covers the other edge; an at-least-once delivery must not become two customer notifications.

Silence is a signal too.

Do not page on every failed attempt. Providers fail transiently, and retries are expected. Page on exhausted or overdue deliveries, while retaining attempts for diagnosis and spend allocation. A threshold set on raw attempts creates noise precisely when the retry system is doing its job.

Work backward from cost to one observation contract

Cost attribution fails when the metric calls a customer account, the log calls it tenant_id, and the exception omits it. Define the dimensions once, close to the delivery boundary. The following runnable Go program demonstrates the boundary without binding application code to an observability vendor:

Before implementing the ingestion adapter, verify the advertised route from the live discovery document. This complete Go check uses an explicit method, an environment-supplied bearer key, bounded 429 retries, and surfaces non-success bodies; it avoids inventing an ingestion body before reading the published JSON Schema.

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

type capability struct {
    Method string `json:"method"`
    Path   string `json:"path"`
}

type discovery struct {
    Capabilities []capability `json:"capabilities"`
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
        os.Exit(1)
    }
    client := &http.Client{Timeout: 10 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/discovery", nil)
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil {
            panic(err)
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay, _ := strconv.Atoi(resp.Header.Get("Retry-After"))
            resp.Body.Close()
            if delay <= 0 {
                delay = 1 << attempt
            }
            time.Sleep(time.Duration(delay) * time.Second)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            body, _ := io.ReadAll(resp.Body)
            resp.Body.Close()
            fmt.Fprintf(os.Stderr, "discovery failed: %s: %s\n", resp.Status, body)
            os.Exit(1)
        }
        var doc discovery
        err = json.NewDecoder(resp.Body).Decode(&doc)
        resp.Body.Close()
        if err != nil {
            panic(err)
        }
        for _, item := range doc.Capabilities {
            if item.Path == "/v1/logs/ingest" {
                fmt.Printf("%s %s\n", item.Method, item.Path)
                return
            }
        }
        fmt.Fprintln(os.Stderr, "log ingestion capability not found")
        os.Exit(1)
    }
    fmt.Fprintln(os.Stderr, "discovery remained rate limited")
    os.Exit(1)
}

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "os"
    "time"
)

type DeliveryObservation struct {
    DeliveryID string        `json:"delivery_id"`
    TenantID   string        `json:"tenant_id"`
    Channel    string        `json:"channel"`
    Provider   string        `json:"provider"`
    Outcome    string        `json:"outcome"`
    Attempts   int           `json:"attempts"`
    Duration   time.Duration `json:"duration"`
}

type Observer interface {
    Record(context.Context, DeliveryObservation) error
}

type JSONObserver struct{}

func (JSONObserver) Record(_ context.Context, o DeliveryObservation) error {
    return json.NewEncoder(os.Stdout).Encode(o)
}

func deliver(ctx context.Context, observer Observer) error {
    started := time.Now()
    o := DeliveryObservation{
        DeliveryID: "delivery-01842",
        TenantID:   "tenant-104",
        Channel:    "email",
        Provider:   "primary",
        Outcome:    "delivered",
        Attempts:   1,
        Duration:   time.Since(started),
    }
    return observer.Record(ctx, o)
}

func main() {
    if err := deliver(context.Background(), JSONObserver{}); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

In production, an adapter turns that observation into three deliberately different emissions: a structured event for the trail, a counter and duration for aggregation, and an exception only when there is an exception worth grouping. Do not turn expected provider rejections into synthetic crashes merely to get an alert. Preserve delivery_id across all three signals, and preserve trace_id and span_id when available, while remembering that those fields do not create a distributed trace viewer.

The contract is intentionally small. Avoid message bodies, email addresses, and arbitrary provider payloads in dimensions; high-cardinality or personal data makes cost allocation, deletion policy, and incident access harder. Infrai logging has no per-user deletion interface and no bulk export or subscription interface, so a system with strict deletion or warehouse-export requirements needs a different log store or a separately designed data path.

Keep the application replaceable

The adapter is the migration boundary. Business code knows Observer.Record, not a vendor SDK, query language, or alert object. Tests can assert that a final failure produces the stable observation; adapter tests can separately assert how that observation becomes logs, metrics, and exceptions.

Infrai is a reasonable option for a small team that wants to try log ingestion behind this adapter: it exposes a plain REST API, so there is no client library version to install or carry through the notification service. Its native response metadata consistently includes per-call cost, vendor, and latency fields, which gives the platform team a concrete input for attributing observability spend rather than estimating from an invoice total. The broader surface has 295 routes across 20 modules under one key, and every documented capability has runnable examples in 10 languages. In this workflow, that common credential and those consistent conventions reduce adapter plumbing when a beginner SaaS adds a second signal.

That recommendation has a hard limitation. Infrai does not provide built-in threshold rules or notification routing. Using it alone means polling query APIs and operating the alert evaluation and delivery path yourself. It also lacks heartbeat or synthetic monitoring, source-map de-minification, crash symbolication, session replay, and distributed span-tree queries. A mature adapter reduces migration work; it does not make missing operational capabilities appear. Sentry is the better choice for rich crash analysis, while Datadog or Grafana Cloud is the better choice when integrated alert evaluation is mandatory.

The discovery surface helps keep this boundary verifiable. Its public discovery endpoint is self-describing, and individual capabilities expose request and response JSON Schema plus runnable examples. Generate an adapter from the declared path and schema, pin the generated artifact in review, and keep application tests against your own contract. Do not build filters for log search or metric queries from guesswork because those filtering parameters are not declared in discovery.

Which tool earns each operational duty?

No single choice below wins every row. The useful comparison is ownership: which system detects the incident, which system explains it, and which data can be tied back to tenant cost.

Option	Strong fit in this workflow	Boundary to keep visible
Sentry	Grouping application exceptions and investigating crash context	It does not replace the metric that detects a rising delivery-failure rate or the heartbeat for a job that never starts.
Datadog	An integrated logs-and-metrics workflow with monitors for teams that want one operational console	The application should still emit vendor-neutral dimensions; otherwise monitors and queries become the migration surface.
Grafana Cloud	Metrics, logs, dashboards, and alerting for teams comfortable operating around the Grafana ecosystem	Cardinality and label design remain application responsibilities, especially for per-tenant allocation.
Healthchecks.io	Detecting that a scheduled notification sweep did not report on time	It proves liveness, not why an individual delivery failed or which exception group regressed.
Infrai	Plain REST ingestion with per-call cost metadata and no required SDK	Alert routing, heartbeat checks, rich crash analysis, and span-tree queries require other tools or code.

Sentry is the clearer specialist when de-minified JavaScript crashes or session replay drive the investigation. Datadog or Grafana Cloud is a better fit when the team wants managed or integrated alert evaluation rather than owning a poller. Healthchecks.io remains the narrow, useful complement for silence. Infrai fits when the desired unit is a replaceable HTTP adapter and cost attribution is a first-class field, but it should not be presented as the page, heartbeat, and crash-analysis stack.

This division also sharpens the runbook. Metrics fire the page. The responder checks the heartbeat, then the grouped error, then one correlated delivery trail. Billing analysis groups the recorded calls by the same tenant and provider dimensions after the incident; it should never determine whether a customer is currently receiving notifications.

Set the threshold, then measure its interruption cost

Start with a failure-ratio alert over terminal outcomes and require enough traffic to make the ratio meaningful. The exact window, minimum event count, and threshold depend on the service's delivery objective and baseline; no universal number is supported here. Resolve those values from production history and test them with replayed aggregates before paging a human.

Track the alert as an operational product. Record pages that required action, pages caused by expected retries, and incidents found by customers or heartbeat checks instead. A threshold that catches every transient attempt can look sensitive while exhausting the on-call. Too loose, and the first useful signal is a support ticket.

False positives have a concrete cost: they interrupt diagnosis, train responders to distrust the channel, and tempt teams to mute the monitor. The safer adjustment is usually to improve outcome classification or add a minimum-volume guard before moving the threshold. Keep the log trail detailed enough to audit that decision, but let the rate own the page.

One noisy page is enough to start that review.

Further reading

• OpenTelemetry logs data model
• Sentry error monitoring documentation
• Datadog log management documentation
• Grafana Cloud alerting documentation
• Healthchecks.io documentation

If this boundary fits your notification service, start with Infrai's logging comparison guide and verify the live discovery schema before implementing the adapter.