REAL CTK WALKTHROUGH
One order. Three repositories. A specific exchange to inspect.
A single order passes through storefront, orders-engine and payments. This local demo uses the same correlation key to narrow the investigation from a multi-repository view to one payment exchange and its source records.
Controlled local demo · No customer data · 1:16 min
01
Keep the same order in view
Open the relation connecting storefront, orders-engine and payments. Choose order-2050 in the correlation-key selector so the view focuses on records for that order rather than unrelated activity.
The flow begins with checkout.submitted between storefront and orders-engine, then continues to payment.authorize between orders-engine and payments. A shared key makes the handoffs easier to inspect together.
02
Inspect the flagged payment exchange
Select payment.authorize, the step with a reported issue. CTK opens the selected exchange and its explanation rather than asking the developer to infer a problem from the diagram alone.
The explanation ties matching send and receive records to order-2050. Matching records establish a correlation between the two sides; they do not prove that payment authorization or the wider business operation succeeded.
03
Go back to the source records
Open Evidence to inspect the records supporting the exchange. Follow the receiver in payments and check its Receive direction, HTTP transport, payment.authorize channel and order-2050 correlation key.
The receiver record reports a health-check problem: payment authorization is unavailable and a settlement dependency timed out. That is a reported cause preserved in the input record, not an independently proven root cause inferred by CTK.
04
Use the evidence to choose the next investigation
Return to the topology with the payment exchange selected. The useful outcome is a narrower question: what is happening at the payments receiver and the dependency named in its record?
This walkthrough stops at source-record inspection. It does not show a payment-service fix or prove a completed payment. Separating that boundary from the observed correlation keeps the next debugging step grounded in the available evidence.
What this demo does—and does not—prove
Controlled local demo with three repositories and real HTTP requests. Service-produced send/receive records were supplied through the supported .ctk/relation.json input, and the payment service was deliberately made unhealthy. The reported cause is demo input. This is not automatic instrumentation of every request, an independently verified root cause, or proof of a successful payment.
Read the on-screen text
- 0:00
One order travels across storefront, orders-engine and payments.
- 0:04
Open their relation in CTK.
- 0:08
Choose the order’s correlation key.
- 0:13
Select order-2050. CTK narrows the view to its records.
- 0:17
Same order. Across all three repositories.
- 0:19
Follow the handoffs for order-2050.
- 0:21
checkout.submitted links storefront to orders-engine.
- 0:25
Next comes payment.authorize, from orders-engine to payments.
- 0:29
The payment step has a reported issue. Select it to investigate.
- 0:35
CTK opens the selected exchange and its explanation.
- 0:39
The send and receive records match for order-2050.
- 0:43
The payments record reports an authorization problem.
- 0:48
Open the two source records behind this exchange.
- 0:53
Follow the receiver’s record in payments.
- 0:57
Receive · payment.authorize · order-2050.
- 1:01
The reported cause is preserved in the receiver’s source record.
- 1:06
A specific exchange. A specific receiver. Source evidence to inspect.