Live Data
Live Data captures pipeline messages at a chosen processing stage, so you can watch real data as it moves through a component. Use it to verify transformations, diagnose routing, and inspect message content at a specific point in the chain.
A capture is a bounded session, not a continuous tail: you set a duration and an event limit, start it, and the results stay on screen as a searchable table you can export.
Availability
Live Data appears on the detail pages of the following components:
| Component | Navigation Path |
|---|---|
| Director | |
| Cluster | |
| Device | |
| Agent device | |
| Target | |
| Advanced Route |
The Pipeline Debugger also offers Live Data as a dataset provider, so a capture can become debugger input.
Running a Capture
With nothing captured yet, the tab shows an empty state and a
| Setting | Notes |
|---|---|
| The processing stage to intercept at — see Capture Locations | |
| 5 to 60; defaults to 60 | |
| 100 to 5,000; defaults to 1,000 | |
| Restricts the capture to messages containing this text | |
| Replaces sensitive values with placeholders before the records reach the browser. On by default. See Masked Captures |
Click
Once they confirm, the bar switches to the running view, reporting that it is capturing and counting the events received;
When the console is served over HTTPS or from localhost, a capture is encrypted for the browser that starts it, with nothing to set. Each record's content — its message and the raw original — is encrypted for that browser, and only that browser holds the key that opens it. What the platform needs to route and label a record stays readable: its time, the Director, device, target, route and dataset it came from, its source, and its sizes.
Where the content is encrypted depends on the Director. A current Director encrypts each record itself, where it captures it, under a key it signs: this is end-to-end encryption, and nothing between the Director and the browser can read the content, the platform included. The platform encrypts the records of an older Director where they enter the platform, so every Director version is covered. The status bar says how far it went:
| Status bar | When |
|---|---|
| A lock and End-to-end encrypted, with an information button | Every record so far was encrypted by the Director that captured it, under a key the console verified |
| A lock and Encrypted between the platform and your browser | Every record so far arrived encrypted, and the platform encrypted at least one of them, for example one from an older Director |
| A warning icon and Some records weren't encrypted | At least one record arrived unencrypted, for example from a platform instance that had not been updated yet during an update. The record is still shown |
The status bar never claims more than every row supports: a single record the platform encrypted makes it Encrypted between the platform and your browser rather than End-to-end encrypted.
Nothing is shown when the browser cannot encrypt: the console is served over plain HTTP from an address other than localhost. The capture then works as before, unencrypted.
The indicator sits beside Sensitive data masked when the capture is also masked, and clears with the rows on
A capture stops when its time elapses, when it reaches its event limit, or when you stop it — whichever comes first. Its results stay on screen until you clear them.
The Directors mark when the capture started and when it completed. These markers are not shown as rows in the table and are not counted in the event totals.
If the connection drops or the server fails the capture, the status bar says so and asks you to start a new one; partial results already received remain.
Checking a Director's Key
The information button beside End-to-end encrypted, D025 FFFF 106A CAAA C506 E1E2 09F9 95DD.
Each Director has a long-lived capture identity, a key it keeps in its data folder as capture_identity.pem, and it signs every capture key with it. When it starts, the Director writes the identity's fingerprint to its log:
Capture identity fingerprint: D025 FFFF 106A CAAA C506 E1E2 09F9 95DD (loaded)
To prove the platform did not swap a key, compare the fingerprint in the console with that log line. They match when the key is the Director's own.
capture_identity.pem holds the identity's private key, so treat it as a secret. Deleting it makes the Director create a new identity, with a new fingerprint, on its next start. A Director without lasting storage, such as a serverless one, makes a new identity each time it starts, and its log line says so.
Capture Locations
The capture location is the pipeline stage at which messages are intercepted. Which locations are offered depends on where you are.
Directors and Clusters
| Location | Description |
|---|---|
| Before pre-processing | Raw data as received, before any pre-processing pipeline runs |
| After pre-processing | Data after pre-processing |
| Before route | Data as it enters routing |
| After route | Data after routing has selected its destinations |
| Before post-processing | Data before the post-processing pipeline runs |
| After post-processing | Final data, as delivered to the target |
Directors and clusters default to Before post-processing.
Devices and Targets
Devices and targets offer the four pipeline stages — before and after pre-processing, before and after post-processing. Devices default to Before pre-processing, targets to After post-processing, since a target sits at the end of the chain and the interesting question there is what actually arrived.
Devices that receive a framed TCP stream additionally offer Raw data, which captures the bytes before any pipeline sees them. This covers TCP devices, and Syslog devices only when they listen over TCP or TLS — over UDP there is no framed stream to capture, so the option is not offered.
Agent devices do not offer raw capture.
Advanced Routes
| Location | Description |
|---|---|
| Before route | Data as it enters the route, before route processing (default) |
| After route | Data after route processing completes |
What a Capture Sees
The component you started from determines the scope:
- Director — everything flowing through that Director, across all devices, targets, and routes
- Cluster — everything flowing through the cluster
- Device — only data originating from that device
- Agent device — only data collected by that agent
- Target — only data destined for that target
- Advanced Route — only data flowing through that route
Masked Captures
A masked capture shows placeholders in place of sensitive values such as card numbers, bank account numbers, national IDs, passwords and keys, and e-mail addresses. The platform replaces them where the records enter it, so a masked value never reaches the browser and is not in what
Whether a capture is masked depends on the role:
| Role | Captures |
|---|---|
Holds the unmasked view (LIVEDATA_READ_UNMASKED) | Masked, unless |
| Lacks the unmasked view | Always masked. The dialog has no switch, and says Sensitive data is always masked. Your role can't see the real values. Ask an administrator for the unmasked view. |
A capture started over the capture WebSocket without saying whether to mask it is masked too. Only a start request that sends "mask": false, from a role with the unmasked view, gets the real values.
The status bar says which kind of capture produced the rows on screen: Sensitive data masked, or a warning icon and Sensitive data not masked. It shows while the capture runs and while its rows are on screen, and clears with the rows on
What Is Masked
The values masked are the ones found by the rules enabled in Library: Sensitive Data Rules, built-in or your own. Every tenant starts with the built-in rules. A rule change reaches capture masking within 30 seconds. If you switch off or hide every rule, masked captures hide nothing.
A masked value reads as [masked:<rule key>], for example [masked:email]. Some rules keep part of the value: a payment card keeps its first six and last four digits (411111******1111), and an assignment keeps its keyword (password=[masked:generic-assignment]).
Masking applies to each record's message and raw original. The text of a marker, the record's source, and the Director, device, target, route and dataset it names are never masked. Replay and BACnet discovery list object names and are never masked either.
The
The Results Table
Captured events appear as a table. Its columns depend on the page, because what usefully identifies an event differs by context:
| Page | Related column | Source | Target | Route |
|---|---|---|---|---|
| Director, Cluster, Advanced Route | Yes | Yes | Conditional | |
| Device | Yes | Yes | Conditional | |
| Agent device | No | Yes | Conditional | |
| Target | No | No | Always |
Every table also carries
A target page relates events to the device they came from rather than showing a Source column, since the page is the source's destination. On an agent device the data source is the device itself, so Source is dropped there too.
The Route Column
One source event produces one row per route it travelled. Without a route column those rows read as duplicate delivery, which is why the column exists.
Routing happens between pre-processing and post-processing, so a record captured before that point does not yet know its route. The column therefore appears only when capturing at Before post-processing or After post-processing. On a target page it is always shown; on an Advanced Route page it never is, because every row there belongs to that one route.
Routes created as quick routes are labelled
Where an event names a device, target, route, or dataset, the cell links through to that component.
Truncated Records
A record too large to carry whole is cut, and the table marks it rather than showing a fragment as if it were complete:
- The
Message cell shows a warning icon and Truncated before the text. - The expanded row shows Truncated, full size and the original size — for example Truncated, full size 5.0 MB — beside the
Message label, or beside theRaw event label when it is the raw original that was cut. - What is shown is the start of the text, not all of it.
Two limits produce the cut:
- The message. The platform cuts a record's message to fit the message broker's per-message limit (its
max_payload, less a few KB for the message envelope). The cut falls on a character boundary. - The raw original. The Director cuts the raw original at 65,535 bytes, the most a capture record's string field can carry. Before this, an oversized raw original wrapped around and showed only a stub.
Records That Could Not Be Shown
When records are lost before they reach the console, a warning above the capture says so. Its title reads N records could not be shown, or Some records could not be shown when a count is unknown. One sentence per reason follows:
| Reason | Reported by |
|---|---|
| could not be passed on by the platform | Platform |
| were in a batch the platform could not read | Platform |
| were dropped while the platform was busy | Platform |
| could not be encrypted by the platform, so they were not sent | Platform |
| could not be sent by the director | Director |
| could not be encoded by the director | Director |
| were dropped because the director's capture buffer was full | Director |
| could not be read by this page | Console |
| were lost for an unknown reason | Platform or Director, with a reason the console has no label for |
The platform drops a record it cannot encrypt rather than send it unencrypted, which is what could not be encrypted by the platform counts. Could not be read by this page also counts an encrypted record this page could not open.
The capture buffer is shared by every capture running on the Director, so the capture buffer was full count may include entries that fall outside this capture.
When the capture spans several Directors, a closing sentence names the Directors that reported a loss.
The notice stays after the capture stops, and clears when you start a new capture or click
A loss in a capture's final batch cannot be reported, because its notice travels in that same batch.
The platform-side reasons and the message cut take effect when the platform is deployed. The raw-original cut and the Director-side reasons need a Director release that carries them.
Searching and Exporting
| Control | Effect |
|---|---|
| Copies the captured output to the clipboard | |
| Saves the capture as CSV, JSON, or ZIP | |
| Clears the results. The status bar stays, with the last capture's settings and its |
An exported file carries both the displayed date and the original wire timestamp, so a script reading it never has to infer a timezone. If a search term was active when you exported, the file records it along with the filtered and total counts — a filtered export is otherwise indistinguishable from a complete one.
Prerequisites
Live Data needs the component to be enabled and to have an active data path. When it does not, the tab explains which condition failed instead of offering a capture:
| Component | Enabled Condition | Connected Condition |
|---|---|---|
| Director | Director must be enabled | Director must be connected |
| Cluster | Cluster must be enabled | Cluster must be connected |
| Device | Device must be enabled | At least one associated Director must be connected |
| Target | Target must be enabled | At least one route must be sending data to the target |
| Advanced Route | Route must be enabled | The route must be running on a connected Director |
Encrypting a capture needs the console served over HTTPS, or from localhost. Over plain HTTP from any other address the capture still runs, unencrypted.
End-to-end encryption needs a Director release that encrypts captures itself. With an older Director, captures are still encrypted where they enter the platform.
Permissions
Viewing the LIVEDATA_READ_UNMASKED). Without it, every capture is masked. See Masked Captures and Roles.