Quick answer: Real-time OEE that does not trigger immediate maintenance action is just expensive surveillance. The Post-Mortem Problem is what happens when you can see every loss as it occurs but the maintenance team finds out tomorrow.
This guide explains the 4 lag-time killers between detection and action, and a 90-day plan to convert your OEE dashboard from a watch-and-report tool into a trigger-and-fix system.
Want OEE captured straight from your machines — no manual logs?
See it liveRelated deep-dives: closing the OEE-CMMS loop · why OEE improvement stalls · maintenance as profit center · Computer Vision OEE.
Most OEE platforms market themselves as "real-time". What they usually mean: data refreshes every minute on a dashboard. What real-time should mean for your plant: the right maintainer's phone vibrates within five minutes of the loss event, with context, asset history, and a one-tap acknowledge button.
The gap between those two definitions is where most of your avoidable downtime lives.
A line goes down at 14:32. Your OEE dashboard shows the loss at 14:33. The shift supervisor sees it at 14:47 when they walk past the screen. The maintenance lead finds out at 16:15 during the end-of-shift huddle.
By 17:00 the maintainer is gone. The work order is written the next morning.
The actual repair happens at 11:30 next day, twenty-one hours after the event. That is the Post-Mortem Problem.
The dashboard was "real-time". The response was not.
If your OEE platform exports a CSV that someone imports into your CMMS each morning, you have engineered a 16-hour delay into your repair loop. The cure: event-driven webhooks.
Every OEE loss above threshold posts a JSON event to your CMMS, which auto-creates a work order with the right asset, the loss code, and the operator who reported it.
When a stop happens, someone has to decide: is this a real failure, or just a quick reset? In most plants that decision lives in one experienced operator's head.
When they are on holiday, real failures get coded as resets and slip through. The cure: codified triage rules at the OEE layer.
Three resets on the same code in one hour → auto-promote to failure, regardless of operator opinion.
The most expensive 30 minutes in your plant is the shift handover. Pending issues get half-described on a whiteboard, half-mentioned in a verbal brief.
Half of them get lost. The cure: shift-bridging tickets.
Any unresolved OEE issue at end of shift auto-creates a handover ticket the incoming shift cannot dismiss without acknowledgment.
Email is a great way to slow down action. The cure: tiered alerts with auto-escalation.
First alert to the on-shift technician's phone within 5 minutes. No acknowledgment within 15 minutes?
Escalate to maintenance lead. No acknowledgment within 30 minutes?
Escalate to plant manager. The clock starts at the OEE event, not at someone reading a report.
Map every loss code in your OEE platform to a work-order template in your CMMS. Build a webhook receiver. Test end-to-end with one line. Define the threshold rules: which losses auto-create work orders, which raise candidates for a planner to approve.
Move beyond "every loss creates a ticket". Use conditions: 3 resets in 1 hour, 8% performance drift from baseline, downtime exceeding 12 minutes on a critical asset. Each condition fires a different action, work order, paging maintainer, halting line, calling quality.
The proof is in mean-time-to-repair. If your detection-to-action loop is closing, MTTR should drop 20–40% in the 90-day window. Plants that go from email-based escalation to mobile push notifications routinely see MTTR fall from 90 minutes to under 40.
Track this single number: median minutes from OEE loss event to first maintenance touch. Starting baseline in most plants: 90–240 minutes. Target after 90 days: under 15 minutes. A plant under 5 minutes has world-class loop closure.
This is a tight integration problem, not a vendor-shopping problem. Read the OEE software pricing breakdown, the Intelligence Gap article, and the closing the OEE loop guide for context.
For micro-stops, yes, you would page maintenance constantly. For major downtime events on critical assets, 5 minutes is the right target. Tune the trigger sensitivity per asset criticality.
False positives kill trust in the system. Start conservative (high thresholds, easy to acknowledge) and tighten over 30 days as you learn the patterns.
Usually no. Existing PLCs feed OEE. The change is in how OEE talks to CMMS, webhooks, not CSV. Mobile maintainers need phones that take push notifications; most already do.
Real-time data without real-time action is observation. Closing the loop requires the trigger fires the work, not waiting for someone to read a dashboard.
The Post-Mortem Problem is the most expensive lag in modern manufacturing. Real-time detection without real-time action is just expensive surveillance.
Close the loop with webhooks, conditional triggers, mobile push, and tiered escalation. Measure detection-to-action latency.
Drive it under 15 minutes. The MTTR drop and avoided downtime pay for the platform in 90 days.
Turn downtime into a number your team can actually act on.
Get a demo
Login
Blog
