Data subscriptions
Everything else in this section is about looking at data. A subscription reverses the direction: data comes to you, the moment it arrives, pushed over a standing connection rather than fetched on a schedule.
Delivery is millisecond-scale inside the platform, and that is not a performance brag, it is a category change: a whole set of use cases only exists below the latency of a polling loop.
Push, not poll
Most integrations ask on a schedule: every minute, every five, every fifteen. That puts a floor under how fresh anything downstream can be, on average half the polling interval, no matter how fast the data itself moves. It also scales badly, because every consumer asks again whether anything happened, mostly to hear that nothing did.
A subscription is a standing request. You say once what you want to hear about, and the platform delivers each new datapoint as it lands.
The two kinds
| Live tail | Durable subscription | |
|---|---|---|
| For | Watching, a person or a chart | Delivering, a system that must not miss data |
| Starts from | Now | Where you left off |
| If you disconnect | You miss what happened while away | Nothing is lost: your position is held on the platform, and delivery resumes from it |
| Acknowledgement | None, it is a view | Each delivery is acknowledged, so unconfirmed data is redelivered |
| You meet it in | Insights Live mode | Integrations built by your team |
The distinction matters more than it looks. A wall display can use a live tail, because a missed minute during a reconnect is harmless. A downstream system mirroring data, or an agent acting on it, needs the durable kind, where a dropped connection is an inconvenience rather than a gap in the record.
Two properties of durable subscriptions are worth knowing even if you never build one:
- Reconnects resume anywhere. Your position is held by the platform, not by the server you happened to be talking to, so a reconnect lands on any instance and carries on. No data loss, no special infrastructure.
- Filtering happens platform-side. You subscribe to the series you care about, and only those are delivered. A subscriber is not flooded with everything and left to discard.
What millisecond delivery opens up
The honest way to see the value: list what is impossible at five-minute latency and routine below one second.
A threshold crossing reaches the person on shift while the excursion is still starting, not on the next dashboard refresh. The difference between reacting and reviewing.
A perception agent is only as fast as its data. Fed by subscription, it evaluates every reading as it lands, which is what makes early-warning agents early.
A system that needs your operational data can subscribe to it instead of receiving nightly exports, always current, no batch window, no reconciliation morning.
Watching a machine through a start-up sequence, or an incident as it develops, with the chart moving as the plant moves. This one you can use today with no code at all.
And the one worth flagging for later: closed-loop reactions, where a detected condition triggers an adjustment, are only responsible at subscription latency. That road runs through the guardrails on the agents page, but it starts here, with delivery fast enough to react to. The chain drawn end to end, a detection function firing, the event waking an agent, the agent's draft reaching a person, is on the functions page. Push delivery is also what moves a model from knowing what exists to knowing what is happening, level two of the twin maturity ladder.
Being honest about the milliseconds
"Millisecond latency" means delivery inside the platform: from a datapoint landing to it being on the wire to subscribers. Your own network path adds whatever it adds, and a subscriber that processes slowly adds more. The claim to design against is no schedule in the way, not a specific number on your WAN. Acknowledged redelivery also means a consumer can see the same datapoint twice after a reconnect, so build handlers idempotent.
The other side of the deal: a durable subscriber that stops consuming leaves the platform holding its undelivered data. Build consumers that keep up, and treat a subscription's credentials like any other integration's, a service account with the narrowest access that works.
Where to start
- See it without writing code: open a series in Insights and go Live. That is a live tail over exactly this machinery.
- Build against it: subscriptions are consumed through the API and SDKs, which is developer territory, and they are the live feed behind most applications built on the platform. Developer and SDK documentation →
- Managing subscriptions in the console sits in the Streams area, whose documentation is being reworked alongside the streaming feature itself.
- Insights Live mode: the no-code way to watch a subscription
- Events: the discrete occurrences worth subscribing to
- AI agents: what continuous watching makes possible
- Digital twins: the live connection that separates a twin from a picture
- Users and access: credentials for a subscribing system
- Architecture: why reconnects resume on any instance