Every plant obsesses over sensor accuracy and PLC tag mapping, then treats the shift boundary as an afterthought. That’s backwards. The moment one crew logs out and another logs in is the single most error-prone event in your entire OEE data chain, and almost nobody audits it systematically. Downtime events straddle the boundary. Reason codes get entered by whoever happens to be looking at the HMI when the dialog pops up, which is often the incoming operator guessing about something they didn’t witness. Micro-stops under a few minutes vanish into the gap entirely. None of this shows up as a system error. It shows up as a KPI that’s just quietly wrong, week after week, until someone finally asks why two crews running the identical shift on the identical line report OEE numbers eight or ten points apart.
This has gotten more urgent, not less. Plants running mixed crews with cobots on the line have asynchronous events firing off machine logic even when no operator is present to attribute them. Add a third shift or a rotating schedule, and you’ve multiplied the number of boundary crossings your data has to survive cleanly every single day. If your MES handoff configuration hasn’t been touched since commissioning, it’s worth assuming it’s leaking data.
The three failure modes at every shift boundary
Before you touch configuration, understand what actually breaks. There are really only three mechanisms, and almost every bad shift-change number traces back to one of them.
1. Straddle events get cut in half or counted twice
A downtime event that starts at 5:52 AM and ends at 6:14 AM, against a 6:00 AM shift change, is the classic case. Depending on how your MES closes out shift records, you can end up with the outgoing shift showing an open-ended stop with no resolution, the incoming shift showing a phantom stop that “started” at shift start with no cause, or — worse — both shifts getting charged the full stop duration because two separate records got created instead of one being split or carried forward.
2. Reason codes get assigned by the wrong crew
Most MES platforms prompt for a downtime reason code either when the stop occurs or when the line resumes. If the stop resumed after handoff, the incoming operator is the one filling in the dialog box for an event they didn’t see start. You get generic catch-all codes — “other,” “unknown,” “changeover” used as a dumping ground — applied to events the new crew has no real information about. This doesn’t just blur root cause; it systematically under-credits whichever failure modes are hardest to diagnose after the fact.
3. Micro-stops disappear in the login/logout gap
Short stops — the ten- and thirty-second ones that never get a manual reason code and rely entirely on automatic PLC-triggered logging — are the most sensitive to any gap between one operator logging out and the next logging in. If your system requires an active operator session to timestamp a downtime bucket, any stoppage that occurs during the login transition simply never gets recorded as downtime at all. It either gets folded silently into runtime or dropped. Multiply a few seconds of blind spot by hundreds of shift changes a year and you’ve got a real hole in your availability numbers, not a rounding error.
Configuring handoff logic correctly
Fixing this is mostly configuration discipline, not new software. Work through these in order.
- Force event-level, not shift-level, closure. Configure the MES so a downtime event is a single record from first-cause to resolution, independent of shift boundaries. The shift a stop gets “charged to” should be a reporting attribute layered on top of the event, not a hard cutoff that splits the event in two. Most modern MES and historian-based OEE tools support this, but it’s frequently left on default behavior, which is boundary-based closure.
- Set an explicit attribution rule for straddle events and write it down somewhere other than in one engineer’s head. The common, defensible rule: attribute the full stop duration to the shift during which the stop began, since that’s the crew whose line condition caused or witnessed the failure. Whatever rule you pick, apply it consistently and make sure it’s documented in your MES configuration notes, not just tribal knowledge.
- Require reason-code entry from the shift that experienced the event start, with a locked or read-only state for the incoming crew. If the outgoing operator left before entering a code, route it to a supervisor queue for follow-up rather than letting the next operator guess. A wrong code is worse than a delayed one.
- Overlap login windows instead of hard-cutting them. Configure a short grace period — commonly a handful of minutes — where both the outgoing and incoming operator sessions are technically active. This closes the blind spot where automatic stop detection has no valid operator session to log against. Check whether your MES treats overlapping sessions as an error state; some do, and you’ll need to explicitly permit it for the handoff window.
- Decouple micro-stop capture from manual login state entirely. Automatic, PLC- or PLC-historian-driven micro-stop detection should run continuously regardless of who’s logged in. Attribution to a shift or operator can be reconciled after the fact; capture should never depend on session state.
- Standardize your shift-change SOP on the floor, not just in the MES. A five-minute verbal handoff — “here’s what’s open, here’s what I didn’t get a code for” — catches things configuration alone won’t. Pair the software fix with a checklist the outgoing operator physically walks through.
Auditing your last 30 days
You don’t need a new tool to find out how bad this already is. Pull your downtime and OEE detail records for the last month and look specifically at the windows around every shift boundary — typically plus or minus twenty minutes.
- Flag every downtime event whose start and end timestamps fall on opposite sides of a shift boundary. Check whether each one appears as a single record or has been split into two.
- Sum total downtime duration attributed within that same window and compare it against your historian or PLC-level stop-detection log for the same period. A material gap means events are getting dropped, not just misattributed.
- Pull the distribution of reason codes entered in the first few minutes after each shift start. A spike in generic or “unknown” codes clustered right after login is a strong signal of guess-and-enter behavior from incoming operators.
- Compare micro-stop counts (sub-two-minute stops) in the ten minutes before and after each shift change against the plant’s typical hourly rate. A dip right at the boundary is your login-gap blind spot showing up in the data.
- Check whether any shift’s OEE consistently comes in higher not because performance is better, but because its handoff window happens to fall during a naturally quiet part of the process — a sign the boundary itself, not the crew, is driving the number.
Done right, shift-change data should be invisible in your dashboards — no telltale spike or dip at the boundary, no cluster of vague reason codes at shift start, no gap between historian-logged stops and MES-attributed downtime. If your last 30 days show none of those patterns, you’re in reasonably good shape. If they show all of them, you’ve just found out why two identical shifts have never once posted matching numbers.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
