The Dashboard Is Green. The Order Is Missing.

The API error rate is low. The workers are running. The browser reported no uncaught exception.

A user says their order never appeared.

All of those observations can be true. We measured the health of individual pieces, while the user described an outcome across several pieces. The missing part is the connection between them.

I do not think the answer is simply to log more. A larger pile of unrelated events gives us more to read, which is not quite the same thing as giving us more to understand.

Start with the outcome we need to explain

For checkout, I would distinguish browser intent, request acceptance, order persistence, payment confirmation, and follow-up work.

These are not synonyms. A click event proves that someone activated a control. A 200 response proves that an HTTP exchange returned that status. A database record proves that an order was stored. A confirmation email proves another effect entirely.

The analytics layer and an operational trace also serve different purposes. Product analytics can describe behavior; operational telemetry needs enough context to reconstruct a specific failure without assuming every recorded click became a completed purchase.

I would define the business success point explicitly, then work backwards to the evidence required at each boundary. Otherwise the most available metric quietly becomes the definition of success.

A request id is useful, but it is not the whole identity

A request id correlates one HTTP attempt. An idempotency key identifies one intent across retries. An order id identifies durable business state. A trace context links spans across participating services.

Keeping these separate is helpful:

{
  "event": "order.persisted",
  "request_id": "req_9c7",
  "operation_id": "checkout_62a",
  "order_id": "order_18f",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "release": "checkout-2026-10-14"
}

These are synthetic identifiers. The record does not include a customer's name, email, address, token, or raw payment data.

A retry gets a new request id but retains the operation identity. A background job can link to the operation after the original request has ended. Depending on timing and instrumentation, a span link may describe that relationship more honestly than an endlessly extended parent span.

Use established trace propagation and instrumentation, such as OpenTelemetry, rather than inventing a collection of vaguely compatible headers. Still validate untrusted incoming context and keep authorization separate from any telemetry identity.

Missing data has several explanations

If a trace is absent, the request may never have happened. It may also have been sampled out, rejected by a collector, dropped from a full buffer, or generated by an uninstrumented component.

Head sampling decides early which traces to retain. It keeps costs bounded, but it cannot know at the start which request will fail late. Tail sampling can select after observing more of the trace, at the cost of buffering, coordination, and its own resource limits.

Neither gives perfect evidence automatically. Keep critical outcome counters and durable business records independently of a sampling decision. Record the telemetry pipeline's own drops and health so absence is less ambiguous.

For frontend error reporting, the same limitation applies. Browser extensions, network conditions, consent settings, and navigation can affect delivery. No recorded exception is not proof that no exception occurred.

Denominators need their own definition

"Twenty failed orders" is difficult to interpret without knowing how many attempts occurred and which attempts count.

Counting API requests exaggerates user intent when retries occur. Counting clicks includes actions rejected before a request. Counting created orders excludes failures before persistence.

For an outcome metric, define both numerator and denominator around the promise being measured. For example: distinct accepted checkout operations that reach a confirmed or explicit terminal state within a chosen interval.

Then describe exclusions: abandoned carts, expected validation failures, test traffic, and operations still inside their allowed processing window. An illustrative target is not a universal SLO.

The arithmetic is usually easy. The difficult part is resisting a reassuring percentage with a poorly chosen population.

Cardinality is a modelling choice

Metrics work well with bounded dimensions such as route templates, status categories, region, and service.

Attaching order_id, raw URLs, or customer email to every metric label creates huge numbers of distinct time series. It also turns the monitoring system into a rather expensive and unsuitable customer index.

Use /orders/:id, not every concrete order URL, as a metric dimension. Put specific identities in controlled logs or traces when needed, with retention and access appropriate to their sensitivity.

Histograms deserve some care too. Percentiles computed independently by instances cannot generally be averaged into the fleet's percentile. Aggregate compatible histogram observations rather than averaging whichever p95 numbers happen to be on the screen.

The goal is not to avoid detail. It is to put detail into the kind of evidence that can handle it.

Frontend context can make a backend trace usable

A server sees requests. The browser knows which route, interaction, and release led to them.

For an error-reporting tool such as Sentry, a release identifier and matching source maps can turn a minified stack into something useful. Upload source maps through controlled tooling; decide whether publicly serving source files is intended. A production error should identify the bundle that actually ran, not the latest source in main.

Session replay can help explain interaction sequences, but I would not enable it broadly without reviewing masking, consent, sensitive fields, retention, and access. "It is an internal admin screen" is often a reason for more care, not less.

Expected cancellation should not appear beside faults as though a user navigating away is a broken system. The AbortController article covers that distinction at the interface boundary.

An alert should name a response

High CPU may deserve investigation. Missing orders deserve investigation for a more direct reason.

Prefer alerts connected to user-visible impact or exhausted safety margins: sustained error-budget consumption, queue age beyond the product allowance, connection-pool waits, failure to complete accepted operations, or a recovery dependency approaching expiry.

The notification needs an owner, a scope, and a useful next action. A chart link is helpful. So are a recent deployment marker and a runbook that says which evidence separates an application failure from a shared-dependency failure.

I would not page someone every time one instance reports a brief spike unless that spike calls for a meaningful intervention. Noise does not stay harmless; it changes what people notice later.

Telemetry is another dependency

Exporters have buffers, network calls, timeouts, and shutdown behavior. A slow collector should not cause the checkout handler to wait indefinitely or allocate unbounded memory.

Use bounded, asynchronous export appropriate to the instrumentation. Decide what can be dropped and what must be durably recorded elsewhere. Business events required for fulfilment belong in a durable mechanism such as the transactional outbox, not solely in a best-effort log stream.

Also test redaction failures and collector outages. Observability should help us explain failure without becoming its next cause or a route for leaking data.

A telemetry event is evidence with delivery conditions, not a second database transaction.

Reconstruct one unsuccessful operation

I would exercise a deliberately failed checkout and try to follow it from browser intent to its final state. Can we distinguish a request that never arrived from an order that persisted but lost its response? Can we find the background job? Can we identify the release and a retry without counting them as two purchases?

If those questions are difficult, another dashboard will not necessarily improve the situation. A better identity or an event at the missing boundary might.

The green dashboard becomes useful when we know exactly what its green means. Until then, I would keep the user's missing order as the more interesting observation.

The final part of this guide covers backups and recovery: what happens when diagnosis is finished and some part of the system actually has to be rebuilt.

Which production question still sends you comparing timestamps across three tools? I'd like to hear the missing connection, not just which monitoring product you use.