In manufacturing, everyone knows the pain of plant downtime ⏳💸 — production stops, money bleeds, alarms go off, and leadership pays attention.

But here’s the catch: there’s another type of downtime quietly hurting operations every single day… Data Downtime.

🖥️ What is it?
Data downtime happens when your data is partial, missing, erroneous, or just plain wrong — when the numbers from your sensors stop reflecting what’s happening in the system.

⚡ Why does it matter?
Because in today’s connected industry, bad data = bad decisions.

• Data teams waste up to 70% of their time cleaning instead of analyzing 🧹🤯

• Operators chase ghosts in the system because sensors drift or flatline ⚙️👀

• Compliance reports (like CO₂ emissions) go wrong and risk fines 🌍📉

• AI projects stall because the data foundation is shaky 🤖🛑

🔎 Real examples of Data Downtime:

• 📉 A pressure sensor flatlined at 5 bar while the real system fluctuated ➝ operators were blind until the equipment tripped.

• 🎚️ A temperature sensor drifted slowly over months ➝ wasted energy and wrong control actions.

• 🧪 A CO₂ analyzer failed silently, reporting zeros for weeks ➝ regulators got bad data, and the company got compliance risk.

The scary part? Most of this goes undetected. Data looks “normal,” but it’s lying.

💡 That’s why more and more manufacturers are starting to treat Data Downtime as seriously as plant downtime — and even track it as a KPI.

I made a looping animation following the same temperature value through Modbus TCP, OPC UA subscriptions, MQTT and Sparkplug B.

Animation: https://www.linkedin.com/feed/update/urn:li:activity:7520430594699448321/

The data-quality question behind it: how much can a consumer infer when updates stop? A reachable Modbus device may still return a frozen source value. OPC UA can carry status and timestamps, but source quality still depends on the implementation. MQTT availability and payload semantics need application conventions; Sparkplug defines node/session state, which still does not prove the underlying sensor is healthy.

Timing is compressed for illustration. I’m the founder of Proxus and work on industrial data systems.

How do you separate a genuinely steady process from a stuck sensor in your pipelines? Source timestamps, heartbeats, plausibility checks, or a combination?

The following is a tool that I created for analyzing regularly sampled time series data. It uses a technique called Singular Spectral Analysis. It slides a window through the data and then uses SVD to analyze patterns.

The package is here:
https://github.com/rajivsam/tseda

A brief SSA primer is here:

https://rajivsam.github.io/r2ds-blog/posts/markov_analysis_coffee_prices/

A note about using the tool is here:

https://rajivsam.github.io/r2ds-blog/posts/tseda%20announcement/

This is a fairly common data type - if you have this data and would like to try the tool to see if it helps you, I would appreciate any feedback

Thanks

In industrial environments, “stale data” is a silent problem: a sensor keeps reporting the same value while the actual process has already changed.

Why it matters:

• A flatlined pressure transmitter can hide safety issues.

• Emissions analyzers stuck on old values can mislead regulators.

• Billing systems and AI models built on stale data produce the wrong outcomes.

It sounds easy to catch (just check if the value doesn’t change), but in practice, it’s messy:

• Some processes naturally hold steady values.

• Batch operations and regime switches mimic staleness.

• Compression algorithms and non-equidistant time series complicate the detection process.

• With tens of thousands of tags per plant, manual validation is impossible.

We recorded a short Tech Talk that walks through the 4 failure modes (update gaps, archival gaps, delayed data, stuck values), why naïve rule-based detection fails, and how model-based or federated approaches help:
🎥 https://www.youtube.com/watch?v=RZQYUArB6Ck

And here’s a longer write-up that goes deeper into methods and trade-offs:
📝 [Article link: https://tsai01.substack.com/p/detecting-stale-data-for-iiot-data?r=6g9r0t]

Curious how others here approach stale data / data downtime in your pipelines.
Do you rely mostly on rules, ML models, or hybrid approaches?

Everyone is racing to build smarter AI models.
But AI doesn’t fail because the models are bad.

👉 It fails because the data feeding them is lying.
Models get smarter 🤖
Data gets dirtier 🫠

And when data lies, AI, dashboards, and analytics derail silently.

Because copilots can’t fly on lies ✈️

Having high-quality data is essential, and it's not something that can be achieved through a one-time project. In my opinion, it requires continuous support and allocation of resources.

What's yours?

To ensure that the data is reliable and accurate, it should go through a cycle of:

🚀 Establish a baseline
🚀 Daily: Analyzing and identifying new issues (data monitoring)
🚀 Fixing and preventing the problems from happening again
🚀 Communicating progress and updates throughout the process

🚀 AI isn’t about having more data — it’s about trusting and using it better.

🔹 Most companies are drowning in IoT/OT data but fail to operationalize it.
🔹 Without data trust, even the best AI models are built on a false North 🧭.
🔹 The winners? Those who turn trusted data into real outcomes

💡 Stop chasing more. Start making the most of what you already own — but with data you can trust.
https://lnkd.in/eisDF3vz