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.
Three 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.
- Connections are capped, and several subscriptions share one. A tenant may hold a limited number of open connections, with several subscriptions sharing each one, so a well-built integration needs very few. Opening one connection too many is refused and closed; adding one subscription too many to a connection refuses just that subscription and leaves the connection running. The connection cap can be raised for a single tenant. Limits and quotas →
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 across your own network. Delivery is also guaranteed rather than exactly-once: after a reconnect the same reading can arrive twice, so whatever consumes a subscription must cope with seeing a reading it has already handled.
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.
A worked example: handling a noisy alarm
Subscriptions deliver readings. The first thing most teams want to do with them is not store them, it is to stop reacting to every single one.
The problem. A pump's discharge pressure carries a high limit, and the limit alarm fires on every start-up, every slug of gas and every transient the process throws at it. Four hundred alarms a month, almost all of them clear within seconds. Somebody suppressed it two years ago, and on the one occasion it mattered nobody was watching. Moving the limit does not help: higher and it misses the slow drift, lower and it fires more.
What the control room actually wants is not is it above 4.5 but has it stayed above 4.5, and that is a question about a stretch of time rather than about a reading.
Why the window has to slide
Tumbling windows cut time into fixed slices, which is right for reporting and wrong here. A twenty-five minute excursion straddling two fifteen-minute slices looks like two partial slices, neither of them sustained, so the rule stays quiet through exactly the event it was built for. A sliding window always has the last twenty minutes in view, whatever the clock happens to say.
The design
Four decisions, and they are decisions about the rule rather than about code:
Only the readings asked for are delivered. The account the rule runs under needs read access to every series it subscribes to; one it cannot read is refused outright rather than arriving as silence, which is worth knowing when somebody adds a series later. Service accounts →
Not by the clock on the wall. That one choice is what keeps the rule right when a reconnect delivers four hours of readings at once. Why arrival time is the wrong clock →
Raise when the whole window has been above the limit; clear only after ten minutes below it. The two thresholds must differ, or the rule flaps at the boundary and you have reinvented the nuisance alarm with extra steps.
One event on the pump, carrying the window it was judged over, how long the condition held and the peak value. The next person to open that pump sees the finding and its evidence together, and every later question can count these events.
The runnable version, for whoever builds it, is in the developer documentation. The same example, runnable →
What makes it survive contact with reality
Three things the person building the rule has to get right, and which are worth asking about when the rule is reviewed:
- A reading can arrive twice after a reconnect, so the rule must not count the same reading twice towards a sustained condition. Writing back is safer than reading: the platform collapses duplicate readings and duplicate events you send it, but the rule's own window is nobody's job but the rule's.
- A window with holes is not a quiet window. If three of the twenty expected readings arrived, the honest output is not "no exceedance", it is that the instrument or the link needs looking at. Missing data must never read as good news.
- A freshly started rule should not be blind for twenty minutes. It should read the last twenty minutes through the ordinary API on start-up, because a restart is most likely during exactly the incident it exists for. And it should confirm a reading as handled only after acting on it, so that a crash cannot leave a silent gap.
What it is worth, and where it goes next
One event a month instead of four hundred alarms, and an alarm the control room has not switched off. The shape generalises further than it looks: sustained above, sustained below, rate of change across the window, the ratio between two series over the window are all the same rule with a different test.
When no threshold over any window can express the thing you are looking for, because the readings never leave their limits and it is the shape that changed, that is where a sequence model starts earning its keep. And when functions ship, this loop becomes a definition the platform runs rather than a process you keep alive, without changing what it produces.
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 →
- In the console, a series' page lists the subscriptions it belongs to. Subscriptions are created and managed through the API, not on a console screen.
- Stream processing: what to do with the data once it is arriving continuously
- 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
- Building AI agents: waking an agent on a reading rather than a timer
- Digital twins: the live connection that separates a twin from a picture
- Users and access: credentials for a subscribing system
- Limits and quotas: how many live connections a tenant may hold
- Architecture: why reconnects resume on any instance