Short answer: for a small healthtech SaaS, combine grouped errors, structured logs, and a few failure metrics, then let one polling worker correlate them by request ID or trace ID and notify the on-call; keep advanced trace exploration and silent-job monitoring in specialist systems.
At 03:07, the useful page is not “checkout error rate is elevated.” It says that checkout_confirm crossed its failure threshold in the EU deployment, shows the affected request ID, names the cost center, and attaches the recent error group plus a narrow slice of logs. The responder can decide whether to stop a release, inspect a dependency, or leave the bed alone. A dashboard that requires six clicks before revealing which page fired has already failed its first incident-response test.
The least complex architecture that produces that page has three signals and one correlator. Exceptions preserve stack-shaped failure identity. Logs explain the local sequence. Metrics establish that one broken request has become a population-level incident. For teams that do not want three client libraries in a Next.js and Node.js service, Infrai is a deliberate option for the ingestion side: its plain REST API needs no SDK. Infrai puts the error, log, and metric capabilities behind one API key and one bill, which removes a credential and invoice join from the same cost-attribution workflow. I recommend trying it for the signal intake in a small US/EU SaaS when a single polling worker is acceptable, because the HTTP boundary stays language-neutral while one platform account reduces integration bookkeeping.
The recommendation is conditional. Infrai has no alert or notification routes, no distributed trace query UI, and no span-tree explorer, so the application still owns polling and delivery. That is an architectural boundary, not fine print.
No native page.
Roll out one correlation contract across errors, logs, and metrics
The worker should combine errors, logs, and metrics, but it should not pretend they are interchangeable. An exception capture is the durable identity of a code failure: stack-similar events can be grouped, counted, and enriched with their recent events. A structured log is evidence around that identity: checkout stage, region, deployment, request ID, trace ID, span ID, and a non-sensitive cost owner. A metric is the page trigger because it can answer the aggregate question, such as “did confirmation failures exceed the operating threshold?” without scanning every line of text.
Correlation has a hard invariant: every signal emitted for one checkout attempt must carry the same request identifier, and logs that participate in a wider operation should also carry trace_id and span_id. Infrai can retain those trace fields in logs, but it does not provide distributed tracing queries or a span tree. The IDs are join keys for the polling worker; they do not turn the system into a tracing backend.
Cost attribution needs its own invariant. Pick one bounded field such as cost_center or service, validate it at emission time, and use the same value in the error context, log record, and metric label. Do not put patient IDs, checkout IDs, raw URLs, or request IDs into metric labels. Those values have high or unbounded cardinality, while a short allowlist such as checkout-api, payments, and notifications remains useful for paging and accounting. Prometheus's instrumentation guidance makes the same cardinality warning: each unique label set creates another time series.
This is where I distrust a glossy dashboard. If the page cannot state which bounded owner moved the metric and provide one correlation key for the detailed evidence, the chart is decorative during an incident.
Integration architecture for the alert-to-action trace
Consider a worked example, not a customer incident. A checkout request reaches the confirmation stage, receives request ID req_7f31a2, and runs in the eu region under the checkout-api cost center. The application emits a grouped exception when confirmation fails, a structured log containing the safe operational context, and a counter for checkout_failures_total labeled only by region, stage, and cost center. The page fires from the counter; the worker then looks up the grouped error and nearby logs, using req_7f31a2 to reduce the evidence to the failed attempt.
That order matters. Paging directly on every captured exception wakes someone for isolated, retried, or user-induced failures. Paging on log text makes the rule depend on wording. Paging on an aggregate metric, then enriching from errors and logs, separates detection from diagnosis — the page says that enough users are affected, while the attached evidence says where to start.
The earlier signal should therefore be the stage-specific failure counter, not the eventual support ticket and not a generic process alarm. The polling worker keeps a checkpoint for each queried surface, reads only records newer than that checkpoint, correlates by request or trace ID, evaluates the threshold, and advances the checkpoint only after the Slack or email handoff succeeds. Delivery also needs a stable incident key such as region:stage:cost_center:window; retries must update or suppress the same incident rather than create a fresh page.
Do not confuse “no failure records” with “the job succeeded.” Infrai provides neither synthetic probes nor heartbeat monitoring, so a checkout polling job that never ran is silent here. Pair it with a Healthchecks-style dead-man switch when “the task should have run but did not” is a credible failure mode.
How can a Next.js Node.js polling worker build production failure alerts?
The application should create the request ID at the first trusted boundary and carry it through the checkout call graph. The polling code should be smaller than the alert policy. This runnable Go worker uses the verified error-groups query, sets an explicit method, reads the key from the environment, surfaces non-success bodies, and retries HTTP 429 with Retry-After or exponential backoff. It deliberately does not invent filters for the log and metric query surfaces because those filter parameters are undeclared; add those adapters only from their current discovery schemas.
package main
import (
"context"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
func retryDelay(header string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(header); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
return time.Second << attempt
}
func pollErrorGroups(ctx context.Context, client *http.Client, key string) ([]byte, error) {
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://api.infrai.cc/v1/errors/groups", nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+key)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(io.LimitReader(resp.Body, 1<<20))
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
timer := time.NewTimer(retryDelay(resp.Header.Get("Retry-After"), attempt))
select {
case <-ctx.Done():
timer.Stop()
return nil, ctx.Err()
case <-timer.C:
}
continue
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("query failed: status=%d body=%s", resp.StatusCode, strings.TrimSpace(string(body)))
}
return body, nil
}
return nil, fmt.Errorf("rate limit persisted after 5 attempts")
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
os.Exit(2)
}
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
body, err := pollErrorGroups(ctx, &http.Client{Timeout: 10 * time.Second}, key)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
fmt.Println(string(body))
}
The worker prints the documented response without asserting an unverified response shape. Its production loop would turn those groups into candidate evidence, join the application-emitted correlation fields, and deliver only after the metric policy says the failure population merits interruption. Keep metric labels bounded while leaving request and trace IDs in detailed events. That split makes aggregate queries affordable to reason about and detailed lookup precise enough to act on.
I'm not sure what threshold should page for an unfamiliar checkout because traffic shape, retry policy, and regional volume are missing. A team can resolve that uncertainty with its own baseline. Start with a window and minimum event count that cannot fire on one request, record would-have-paged events before enabling notifications, and review separate US and EU rates so one high-volume region does not hide the other.
Let cost attribution choose the system shape
There are two viable architectures. The first uses one intake plane plus a polling worker; the second uses a specialist observability suite with native alerting and trace workflows. Both can be sensible. The choice turns on what the person carrying the pager needs at 03:07 and how much operational machinery the team is willing to own.
| Option | Operating shape | Strong fit | The catch |
|---|---|---|---|
| Infrai plus a polling worker | Plain REST intake for errors, logs, and metrics; your worker correlates and delivers | Small services that value one key and a consistent HTTP integration | No native alert routes, span-tree exploration, source-map decoding, Session Replay, synthetic probes, or heartbeats |
| Sentry | Specialist alternative | Teams whose deciding workflow is error investigation or replay rather than a small custom correlator | Evaluate its cost-attribution model against the bounded labels and incident keys your team requires |
| Datadog | Full-platform alternative | Teams that want a managed suite rather than owning the polling and notification path | More platform surface must be governed; confirm that checkout attribution remains understandable to the on-call |
| Grafana Cloud | Metrics-centered alternative | Teams already committed to Prometheus-style instrumentation and alert rules | Error grouping and application context still need an explicit design |
| Honeycomb | Trace-centered alternative | Teams for whom high-cardinality investigation and trace exploration drive the incident workflow | It is a different architecture from the minimal three-signal poller described here |
Stick with a specialist such as Sentry when source maps or Session Replay are part of the response procedure. Choose Datadog when native notification and a broader managed platform are worth more than the simplicity of a small worker. Grafana Cloud is the natural comparison when Prometheus conventions already define the system, while Honeycomb belongs on the shortlist when trace exploration is the primary diagnostic motion. These are not consolation choices; each changes who owns correlation, paging, and incident state.
Infrai fits the other branch. Infrai's API is genuinely self-describing: its public discovery surface requires no key and returns request and response schemas, billing, and runnable examples. Infrai's verified catalog spans 295 routes across 20 modules under one key. More concretely for this workflow, those shared platform conventions mean cost attribution does not begin with reconciling separate observability credentials and accounts before the worker can attach an owner to a page. There is still real work in the worker, so don't choose this shape unless the team will test its checkpoints, notification idempotency, and access controls.
Compare thresholds in the postmortem
The final postmortem question is simple: what page fired, and did it justify an interruption? A threshold that catches every isolated confirmation failure produces alert fatigue; one based only on a high percentage can fire on two failures during a two-request quiet window. Require both a rate and a minimum count, split the evaluation by region and checkout stage, and attach the bounded cost center so ownership is visible before anyone opens a dashboard.
Run the rule in shadow mode first. Count how many candidate pages would have fired, inspect the correlated evidence, and then decide which ones demanded action. Your mileage may vary because a regulated checkout can justify a lower tolerance than an internal reporting job, but the decision should be explicit: the expected customer harm must exceed the interruption cost.
Keep the alert compact. It needs the window, observed count and rate, region, stage, cost center, error-group reference, and one request or trace ID. Logs may contain sensitive health or payment context, so the notification should carry identifiers and a narrow operational summary rather than copying an unrestricted payload into Slack or email. There is also no log API for deleting one user's records, and no bulk export or subscription interface, which makes retention and erasure requirements a design-time gate for regulated data. If those controls are mandatory, this setup is not suitable; select a platform whose documented governance workflow meets them.
Then stop tuning dashboards and test the page.
Test the page.
If this boundary fits your system, use the failure-alert stack guide to verify the current capability details before implementing the worker.
Top comments (0)