An Eventstream carries live ticket-scanner events from a museum branch's turnstiles through a filter step and into an Eventhouse destination. Visitors keep scanning tickets all afternoon, but the destination stops receiving any new events partway through the day. What is the best way to pinpoint where in the Eventstream the data flow actually stops?

Fabric's Eventstream visual editor lets an engineer inspect a live data preview at each individual node in the flow, so checking the source node first confirms events are still arriving from the turnstiles, and then checking the filter node and the destination node in sequence isolates the exact point where volume drops to zero, whether that is a broken filter condition, a failed transform, or a destination-side rejection. This node-by-node approach is far more precise than guessing at which layer failed. Assuming the destination Eventhouse is entirely offline and restarting the whole capacity is a disruptive, unfocused action that would interrupt every other item sharing that capacity and still might not address a filter-step problem within the Eventstream itself. Rebuilding the Eventstream from scratch discards a working configuration without ever learning what actually broke, risking the same failure recurring. Checking physical network cabling at the branch assumes a hardware-layer cause with no evidence yet that the turnstiles themselves stopped sending, when the stated symptom is that visitors keep scanning tickets normally. As a concrete first step, start the preview check at the source node, since confirming events are still entering the Eventstream immediately narrows the search to everything downstream of that point.