Use Cases

Checkout is failing. Which orders, and why.

During a sale the question is which customers lost their basket and what stopped them. One order id carries the answer across all three surfaces.

signal POST /checkout error rate 8.4% · threshold 1%

The path

One order, from the alert to the timeout

order_8421 is a real order that failed. Every surface below is filtered to it, so nothing has to be matched up by timestamp between two tools.

order order_8421 /alerts /traces /errors T+0:00 T+0:25 T+2:10

alert T+0:00 · order order_8421

The alert fires on the checkout route only

Error rate on POST /checkout crosses its threshold while the rest of the site holds. That scoping is the first fact: the payment path is failing while the sale traffic is fine.
trace T+0:25 · order order_8421

The trace ends at Stripe

Open one failed order and the waterfall is unambiguous. Three retries sit at the bottom, red, each timing out at exactly 1.75 s, the client's own deadline.
logs T+2:10 · order order_8421

The logs say the pool was empty

The lines written during those spans carry the same trace id. Retry budget exhausted, then connection pool at capacity. The timeout was a symptom of waiting for a connection.

outcome

Pool raised and the retry budget cut to two. Checkout error rate back to baseline within one evaluation window.

What it does

Business ids are just attributes: Set order.id on the span once and it is filterable everywhere spans are: the trace list, the error issue, the log search. No separate index to maintain.
Outbound calls are spans too: The Stripe call is a client span with its own duration and status, so a third-party timeout is measured rather than inferred from your own error rate.
Logs are joined to the span: The lines behind a span are reached from the span, with no text query narrowed by hand to the same minute. That is the step that usually costs the most time.