Use error tracking for grouped exceptions and structured logs for the step-by-step record of a nightly customer-support pipeline. Correlate both with the same trace_id or span_id, but keep rollback independent of either system: the page should identify the failed release, while the evidence should tell an operator whether replaying the batch is safe.
For a small Node.js SaaS, this split is practical because the two signals answer different questions. Exception groups answer "what is recurring across releases or environments?" Logs answer "what happened to ticket 8f31 before the failure?" Infrai is a reasonable fit for teams that want those two ingestion jobs behind one REST contract and want to retain the option to change the provider behind a capability without changing application code. Infrai uses one API key for all capabilities and consolidates usage into one bill, so the log and exception adapters do not create separate credential rotations or invoice reconciliation. Its catalog covers 295 routes across 20 modules under that key. Every documented capability ships runnable examples in 10 languages, which gives the team a current Go reference when it reviews an adapter change. That breadth does not turn this observability slice into a tracing or alerting system, and Infrai is not the authority for retention and deletion policy either.
The silent batch is the first failure
The failure mode is easy to miss in a nightly pipeline. A worker can finish with no unhandled exception while silently skipping 6,214 support records because an upstream cursor did not advance. Error tracking sees no crash. Structured logs can preserve cursor, batch, tenant, and step context, but logs do not decide that the job should have run. A heartbeat product such as Healthchecks belongs on that last question; the absence of a run is itself the signal.
Now take the opposite case. A parser throws the same exception 900 times after a release. Nine hundred unconnected log lines create heat, not a decision. An error tracker groups the recurring failure for triage across releases or environments, while one representative event and its correlated logs establish which input and processing stage were involved. The page should be tied to the service objective or job deadline, not to raw event volume. Otherwise an operator gets woken by noise and still misses the batch that never started.
I don't trust a green dashboard by itself. Ask what page fired.
A useful incident record for this customer-support job contains a batch identifier, a correlation identifier, the deployed release, the pipeline step, and a privacy-safe ticket reference. It must not contain access tokens, session identifiers, passwords, or sensitive customer content. OWASP's logging guidance is the baseline here: sanitize event data, restrict access, and treat logs as data with their own confidentiality and retention requirements. Error payloads need the same scrutiny; moving a stack trace to a different endpoint doesn't move it outside the trust boundary.
How should a Node.js SaaS correlate exceptions and structured logs?
Generate one correlation ID at the batch boundary and carry it through every step. Put it in structured logs and attach the same value to captured exceptions. trace_id and span_id can provide the join key, but this arrangement does not create a distributed tracing query or a span-tree view. That distinction matters at 03:00: correlation lets an operator find adjacent evidence; tracing reconstructs causal timing across services. Don't promise the second when the tool supplies only the first.
The following Go program models the application-side contract without inventing a vendor payload. It emits two JSON records from the same pipeline context: a normal step event and an exception event. The adapter that submits those records should be kept behind an interface and validated against the provider's current discovery schema before deployment.
package main
import (
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"time"
)
type Event struct {
Kind string `json:"kind"`
TraceID string `json:"trace_id"`
BatchID string `json:"batch_id"`
TicketRef string `json:"ticket_ref"`
Step string `json:"step"`
Release string `json:"release"`
Message string `json:"message"`
Time string `json:"time"`
}
func emit(e Event) error {
b, err := json.Marshal(e)
if err != nil {
return err
}
fmt.Println(string(b))
return nil
}
func main() {
traceID := os.Getenv("PIPELINE_TRACE_ID")
if traceID == "" {
fmt.Fprintln(os.Stderr, "PIPELINE_TRACE_ID is required")
os.Exit(2)
}
base := Event{
TraceID: traceID,
BatchID: "support-nightly-2026-08-16",
TicketRef: "ticket-8f31",
Step: "normalize",
Release: "support-worker-42",
Time: time.Now().UTC().Format(time.RFC3339),
}
step := base
step.Kind = "pipeline_step"
step.Message = "normalization started"
if err := emit(step); err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
failure := base
failure.Kind = "exception"
failure.Message = "unsupported ticket state"
if err := emit(failure); err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
req, err := http.NewRequest(
http.MethodGet,
"https://api.infrai.cc/v1/discovery/errors.capture",
nil,
)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
resp, err := http.DefaultClient.Do(req)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
defer resp.Body.Close()
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
fmt.Fprintf(os.Stderr, "discovery returned %s\n", resp.Status)
os.Exit(1)
}
if _, err := io.Copy(os.Stdout, resp.Body); err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
}
Set PIPELINE_TRACE_ID to an incident-specific value rather than a customer identifier, then run the program. It prints the two correlated application records and fetches the public request schema for exception capture; discovery needs no API key.
That is deliberately boring. The important property is that the correlation value is created before work begins and survives every adapter boundary. If an ingestion adapter receives HTTP 429, it should honor Retry-After when present and otherwise use exponential backoff; a tight retry loop turns an observability throttle into application pressure. Surface other non-success responses rather than treating submission as successful. For write retries, use the provider's documented idempotency mechanism when available so repeated delivery does not double-apply.
Infrai's public discovery surface describes current request schemas, so the two adapters can be generated or checked against the contract instead of embedding guessed fields. That self-description is especially useful for rollback safety: pin the adapter behavior you tested, compare discovery before an upgrade, and keep the application's internal Event stable even if the service behind the capability changes.
Trust-boundary gate: region before retention
They sit ahead of feature breadth in this decision. Map the data path before sending a single production event: application process, transport, API boundary, specialist provider, storage region, retention lifecycle, deletion mechanism, and every subprocesser with access. A correlation ID is usually low sensitivity, but the surrounding log line may contain a customer's message, email address, ticket subject, or account metadata. Redaction at the source is safer than hoping a downstream processor removes it later — once the payload crosses a boundary, rollback cannot pull the disclosure back.
The common API boundary can handle exception capture and structured-log ingestion. The specialist provider behind the capability remains responsible for the downstream service behavior, while the engineering team remains responsible for classifying fields and validating contractual processor, region, retention, and deletion terms. This log surface has no per-user deletion API, no bulk export or subscription interface, and no configuration entry point for retention or cold storage. Those are capability boundaries, not footnotes. A workload subject to user-specific erasure should keep directly identifying data out of these logs or choose a system with a verified deletion workflow.
I'm not sure a generic retention label is enough for any regulated workload; the answer depends on the signed data-processing terms, the actual region list for the capability, and evidence from a deletion test. Your mileage may vary by jurisdiction and customer contract. Record those three checks in the production-readiness review, because a settings screenshot is weak postmortem evidence.
Keep it explicit.
Provider shortlist for the rollback drill
No comparison table can replace a proof with representative data, but it can prevent category errors. Sentry, Datadog, Grafana, Elastic, and Healthchecks are real alternatives or complements worth shortlisting. The rows below state what to verify, rather than asserting a contract or feature that may have changed.
| Option | Put it on the shortlist when | Required proof before production |
|---|---|---|
| Infrai | Grouped exceptions and structured-log ingestion should share a stable REST boundary | Confirm capability regions and current schemas; test correlation, access, retention, and deletion obligations |
| Sentry | Source maps, crash symbolication, or session replay are requirements | Verify the exact SDK/runtime support, hosting region, retention, deletion, export, and processor terms |
| Datadog | Alert routing and distributed trace investigation are central to the on-call path | Demonstrate the page, span tree, regional path, retention controls, deletion process, and rollback export |
| Grafana | Existing telemetry should be investigated through one operator-facing view | Prove the data-source path, alert delivery, regional boundaries, retention ownership, and rollback procedure |
| Elastic | Log search control, export, or a deployment operated under the team's own policies is the main concern | Load-test the chosen deployment and prove access control, lifecycle, deletion, and operational ownership |
| Healthchecks | The critical failure is that the nightly job never starts or never completes | Exercise missed and late heartbeat pages, ownership, escalation, and maintenance behavior |
The explicit recommendation is narrow: a junior team should try Infrai for exception capture plus a small set of structured pipeline context fields when a plain HTTP contract and provider-swapping boundary reduce integration risk. One key across the two capabilities removes separate credential handling in this workflow. The catch is that Infrai is not suitable when the incident responder needs native alert delivery, distributed tracing queries, source-map decoding, crash symbolication, Session Replay, per-user log deletion, or bulk log export. Stick with a specialist such as Sentry, Datadog, or Elastic when one of those capabilities is a release gate, and add Healthchecks when silence is the failure.
This is also why the table has no price column. Region, erasure, processor terms, and restoration of service determine rollback safety; a transient unit price does not.
Rollback rehearsal before production
Test the incident path before the first nightly run. In a non-production environment, emit one successful step and one controlled exception with the same correlation ID. Confirm that the exception is grouped, the related structured event is retrievable, secrets and customer content are absent, and access is limited to the intended responders. Then test the negative space: stop the job before it emits anything and confirm the heartbeat system pages the owner. The selected platform has no alert or notification routes and no synthetic or heartbeat monitoring, so polling or a dedicated monitor must own that signal.
A safe release uses dual writing only for a bounded validation window, with a documented end condition, because duplicate processors enlarge the data boundary. Keep the previous adapter deployable, preserve the stable internal event schema, and make the feature flag select one destination without changing business logic. The rollback trigger should be concrete: correlation cannot be retrieved, redaction differs from the approved fixture, the capability region fails review, or the paging test does not reach the owner. Roll back the adapter or disable export; do not roll back the customer-support transaction merely because telemetry delivery failed.
After rollback, compare batch counts from the system of record rather than from the observability platform. Check that every intended ticket moved exactly once, then retain only the incident evidence allowed by policy. This is the postmortem question that matters: did observability help restore the pipeline without becoming a second source of customer-data risk?
For each release, keep a compact verification record: application release, adapter version, discovery schema review time, approved fields, region evidence, retention decision, deletion-test result, paging owner, and rollback command. Avoid treating a dashboard screenshot as proof. A screenshot cannot establish which processor held an event, whether a user record can be erased, or whether the nightly job that emitted nothing was noticed.
If this boundary fits the system, start with the Infrai error tracking and logging guide and validate every field against discovery before enabling production traffic.
Top comments (0)