One thread across six services
How CausalThreads reconstruct a cross-system storyline — from the first event to the final outcome — without asking your services to know about each other.
A reservation is born in the booking service. Identity verifies the guest. Billing authorizes the card. An access device cuts the digital key. A notification goes out. A workflow closes the loop. Six services did their job — and when something goes wrong three days later, six teams open six dashboards.
This is the gap CausalThreads close.
Traces: the local story
Each service’s activity around the reservation lands in a Trace — the localized flow of events bound to one entity:
system_domain: 'booking',system_entity: 'reservation',system_entity_id: 'resv-011'- a start and end timestamp
- the primary actor that drove it
A trace answers the local question: what happened to this reservation inside this process? It’s the unit a single team debugs with.
Threads: the storyline
A CausalThread links those traces into one narrative. The booking trace, the identity check, the payment authorization, the device signal — each keeps its own boundary, but they share a causal_thread_id. The thread carries the entity coordinates and, critically, an outcome:
outcome: 'approved' | 'error' | 'abandoned' | ...The outcome is what turns telemetry into operations. “This thread ended in abandoned” is a business fact, not a metric. You can count abandoned threads by domain, walk any one of them end to end, and see exactly which trace the story died in.
Nobody had to integrate with anybody
The important part: the booking service never imported the billing service’s tracer. Each service emits its own events with its own entity coordinates; Vectry assembles the thread at the data layer. The systems stay decoupled — the story gets coupled, which is what you actually wanted.
What this looks like in an incident
Instead of correlating timestamps across six log stores, you resolve the thread for resv-011 and read it like a transcript: every trace, every event, every actor, in causal order, closing with the outcome. If an EventExplanation has been generated along the way, the “why” is one query further.
Six services. One thread. One answer.