From 4 Hours to 12 Minutes: Tracing a 128°C Boiler Spike Back to Its Cause
Before: 4 hours, three people, one shared spreadsheet.
After: 12 minutes, one person, one query.
That’s the difference between how a boiler over-temperature incident used to get diagnosed on a factory floor, and how it gets diagnosed once the plant’s logs are actually connected to each other. Below is a demo scenario — not a customer case study — built on Rootr’s factory-log data model to show what changes when the second version becomes possible.
The Incident
A boiler’s outlet temperature climbs to 128°C, well above its 110°C operating ceiling. A safety interlock trips and the line stops. Nobody is hurt, nothing breaks, but the line is down until someone can say, with confidence, whyit happened and that it won’t happen again in the next hour.
Before — What the 4 Hours Actually Looked Like
The temperature log lives in the SCADA historian. The maintenance log — when the feed pump was last serviced — lives in a separate maintenance ticketing tool. The batch schedule — what was actually running through the line at the time — lives in a spreadsheet the shift supervisor updates by hand. The valve control log lives on the PLC itself and has to be pulled by someone with plant-floor access.
To reconstruct what happened, an engineer has to: export the temperature log, cross-reference timestamps against the batch schedule spreadsheet, ask the maintenance team when the feed pump was last serviced, walk out to the PLC to check the valve position log, and then manually line all four of these up on a timeline by hand — usually in a fifth spreadsheet. Four hours later, the answer is usually right. But it took four hours, and it required three people who each held one piece of the picture.
What Changed
Instead of four systems that don’t talk to each other, the same four data sources — temperature readings, maintenance records, batch schedule, valve control log — get pulled into one place with their relationships already defined: which batch was running feeds into which valve setting, which valve setting connects to which maintenance record, which maintenance record connects to which technician and which date. That connection is defined once, when the data is set up — not re-created by hand during every incident.
When the spike happens, one person asks a plain question — what happened to the outlet temperature on Line 3 in the last hour, and what changed right before it — and the system walks those pre-defined connections automatically: it pulls the temperature trend, matches it against the batch that was running, checks whether the feed pump’s last maintenance falls inside the relevant window, and checks whether a valve setting changed right before the spike. The engineer isn’t hunting across four tools anymore; they’re reviewing one assembled timeline and confirming it.
The 12-Minute Answer
In this scenario, the feed valve had been adjusted 40 minutes before the spike, during a shift changeover, and the batch running at the time required a lower flow rate than the valve was set for — a mismatch that wouldn’t be obvious from any single log, only from seeing the valve change, the batch requirement, and the temperature trend lined up on the same timeline. That correlation, which took four hours to assemble by hand in the “before” version, took 12 minutes to confirm when the timeline was already built.
Why This Matters Beyond One Boiler
The specific fix — reset the valve to the batch’s required flow rate — isn’t the interesting part. The interesting part is where the 3 hours and 48 minutes went: not into fixing anything, but into finding four disconnected records and manually proving they told one story. That’s the same tax described in “Why Root Cause Analysis Always Takes More Than Three Hours” — just wearing a manufacturing hat instead of an SRE one. Any team running production logs, maintenance records, and change history in separate systems is paying this tax on every incident, whether the line makes boilers or ships code.
Note: this walkthrough uses a demo dataset to illustrate the workflow, not a named customer’s production incident. No specific customer results are being claimed here.