# Condition Monitoring: Shift-Level Diagnostic Playbook - Canonical: https://pearlgateway.net/docs/condition-monitoring-shift-level-diagnostic-playbook/ - Updated: 2026-10-05T00:04:00+00:00 Condition monitoring in a warehouse is often imagined as a permanent wall of vibration sensors, desktop software and carefully scheduled route-based readings. In practice, the most immediate and actionable diagnostic loop runs at shift level: a technician hears a bearing that does not sound right, a controls engineer sees a photoeye re-triggering five times per hour, a team leader notices a subtle change in how a pallet enters a lift. These are raw condition signals. The Shift-Level Diagnostic Playbook is a structured method for converting such signals into evidence, deciding what must be acted on during the current shift, and closing out the fix so the fault does not quietly return tomorrow. This article explains how a warehouse operator, maintenance engineer or controls specialist can build and use such a playbook without introducing heavy process or unnecessary downtime. ## How Shift-Level Condition Monitoring Differs from Scheduled Surveys Periodic condition surveys are cross-sectional snapshots. A weekly infrared scan, a monthly vibration route or a quarterly lubrication analysis looks at many assets at a fixed moment in time. Shift-level monitoring is different in three important ways. First, it is continuous and opportunistic. The conveyor system runs for eight or twelve hours, and every alarm, jam, speed drop and unusual noise is a potential data point. The shift playbook defines how to capture those observations before they are lost. Second, it is interactive. The person monitoring can change a load condition, clear a jam, or ask the control room to run a specific test sequence. This allows a rapid hypothesis-to-test loop that a scheduled survey cannot offer. Third, it is closer to the operating context. A cold morning start, a change in carton mix, or a partial staffing of induction stations all influence machine behavior. Shift-level monitoring must interpret condition data in this context rather than against a clean baseline. The playbook does not replace scheduled surveys. It feeds them. Repeated shift-level findings become work requests for deeper analysis, and scheduled survey results help calibrate what a normal shift-level signature should look like. ## Reading the Asset Interaction Map Before You Walk the Floor Most warehouse faults are not single-component failures. They are interaction failures. A palletizer cycle-time delay creates an empty slot in the takeaway conveyor, which changes the sorter gap pattern, which causes a downstream diventer to mistime, which produces a jam at a transfer point. A playbook built around component names will miss these chains. The better starting point is an asset interaction map: a simple diagram or list showing which components load, unload, communicate with, or mechanically load one another. Before starting a diagnostic follow-up on any alarm, ask three questions. - What feeds this component? If it is a conveyor, what is the upstream device and what condition does the upstream device need to maintain? - What does this component feed? A downstream sensor, a lift, a merge point or a stretch wrapper will all react to upstream behaviour. - What does this component share? Shared electrical supply, shared air supply, shared frame members and shared control network segments all create interaction paths that are easy to misread as local faults. ### Conveyor, Sorter, and Lift Interactions Worth Noting The most productive interaction paths in a typical automated warehouse include bearing housing temperature changes that shift photoeye brackets, belt splice wear that changes tension and creates intermittent tracking faults, drive roller slip that triggers both a jam alarm and a speed feedback alarm on the same motor, and lift door edge wear that stains product but also causes sensor false triggers on the next cycle. Each of these looks like a local failure when viewed in an alarm log, but the condition evidence only makes sense when the interacting components are considered together. ## Playbook Structure: Triggers, Triage, and Time Boxes A shift-level playbook is not a long procedure document. It is a short decision framework that can be applied under time pressure. Each diagnostic sequence starts with a trigger, passes through triage, and is deliberately time-boxed so that one fault does not consume the entire shift. ### Trigger Events That Start a Diagnostic Sequence A diagnostic sequence should start from a defined event, not from a general sense that something is wrong. Common triggers include a repeating alarm code, a jam that appears more than twice in one hour, an operator comment that a sound or vibration has changed, an unplanned stop longer than a defined duration, or a trend irregularity observed on a control screen, such as a drive current that climbs steadily across two hours. Each trigger should map to a short list of probable interaction chains in the asset map. ### Triage Rules and the 20-Minute Boundary Triage works best when it is deliberately blunt. On arrival at the asset, the technician classifies the situation into one of three states: safe to keep running with observation, needs a minor adjustment during a scheduled window, or requires immediate shutdown and escalation. The playbook should include a time box, typically around twenty minutes, for the initial diagnostic effort. Within that boundary, the technician can gather evidence, test one or two simple hypotheses, and either resolve the issue or escalate it. The purpose is not to limit good work; it is to prevent a single intermittent fault from causing the team to lose situational awareness over the rest of the system. When the time box expires, the response moves to the escalation boundary defined later in the playbook. ## Failure Coding at the Shift Level: Less Taxonomy, More Signal Failure coding is often treated as an administrative burden, but at shift level it is a communication tool. The goal is not a perfect taxonomy; it is a code that lets the next shift, the spares coordinator and the reliability engineer understand what was seen and what was changed. A practical shift-level code has four parts. - Mode of failure: E for electrical, M for mechanical, C for control-logic, S for structural or support, O for operational such as product jamming or misalignment caused by load characteristics. - Component group: D for drive, SE for sensing, BE for belt, LI for lift, SO for sorter, PA for palletizer. - Observed cause: such as wear, contamination, loose, misadjusted, overloaded, or degraded. - Contributor: the interaction path that allowed the condition to become a fault, such as upstream misalignment or thermal drift. A code of **M-BE-WEAR-DOWNSTREAM-OVERLOAD** is more useful than a free-text note that says belt worn. It tells the next shift that a mechanical belt fault was caused by wear, and that the contributor was an overloaded condition from downstream. The coding scheme should be kept small enough to be memorized by the team, and it should be updated with the maintenance management system before the shift handover is complete. ## Collecting Condition Evidence Without Breaking the Rhythm Evidence collection in a running warehouse has to happen quickly and safely. It cannot stop production for an extended measurement campaign. The playbook should distinguish between evidence that is worth capturing in the moment and evidence that will be available later from historians or logs. ### What to Capture The most valuable evidence is a short time series, not a single number. For a drive, capture the current and speed over a five-minute window during the failing condition. For a sensor, capture the count of false or repeated triggers over a defined period. For vibration, capture an overall level and a note of whether the frequency sounds blade-pass, bearing, or structural in nature. For thermal, capture an infrared image plus the ambient temperature and load at the time. Photographs of the physical condition, with a scale reference and a timestamp, are always useful. Also capture the context: which product is running, what the upstream machine was doing, and whether the condition occurs during acceleration, deceleration, or steady-state running. ### What to Consciously Ignore Time pressure can lead to evidence overload. The playbook should state what to ignore during the initial investigation: long historical trend reviews of unrelated assets, detailed analysis of alarm text from systems that are clearly upstream of the problem, and volunteer observations from multiple operators that cannot be tied to a specific timestamp. These may matter later, but they do not belong in a shift-level diagnostic window. Every hour spent reviewing unrelated logs is an hour that the actual intermittent fault continues to run. ## Diagnostic Decision Table: Symptoms, Interactions, and Escalation The following decision table is a working example for a typical automated warehouse with conveyors, sortation, lifts and palletizing. It is intentionally specific to the shift-level context and should be adapted to the site asset map, OEM documentation and site risk profile. Observed Symptom | Likely Interaction Chain | Evidence to Capture Before Action | Shift-Level Triage Action | Escalation Boundary Intermittent jam at a transfer point, twice in 30 minutes | Upstream photoeye contamination reducing detection range, causing downstream belt to start late | Count sensor triggers for 10 minutes; capture a photo of the sensor face; check belt start delay | Clean sensor face, adjust bracket if permitted by site procedure, observe for 20 minutes | Escalate if the jam repeats after cleaning and adjustment; do not loosen sensor brackets without approved adjustment instructions Drive current trending upward over two hours with no product change | Bearing friction increase or belt tension rise; may involve coupling degradation | Log current and speed every 5 minutes for 20 minutes; listen for tonal frequency change | Reduce load if safe and within production rules; inspect accessible bearing and belt visually | Escalate to full mechanical inspection if current exceeds the value specified in site maintenance instructions Lift cycle time gradually lengthening across the shift | Lift guide wear increasing friction, or brake drag; interacts with load position sensor | Record cycle time and brake release voltage or air pressure during three consecutive cycles | Check for debris on guides; verify brake is fully releasing | Stop use if brake drag is suspected; lockout and isolate before any internal inspection Sorter diverts a small percentage of cartons late, causing downstream merge gaps | Sorter position encoder drift or worn divert paddle causing timing offset; interacts with photoeye calibration | Capture 20 consecutive divert events with timestamps and final positions | Compare timing to a known-good adjacent sorter; soft-recalibrate if site procedure allows | Escalate to controls engineering if offset is present on more than one sorter lane Intermittent false low-pressure alarm on a conveyor air system | Multiple actuators cycling at the same time, or a slow leak interacting with a dryer purge cycle | Record pressure trend for 15 minutes alongside a note of which actuators are active | Check for visible leaks; confirm whether the alarm correlates with a specific machine cycle | Escalate if pressure drops below the minimum required by the machine safety system ## Interpretation Errors That Turn Evidence into Misdiagnosis Shift-level diagnosis fails more often from interpretation errors than from missing data. The first error is confirmation bias. A technician who assumes the jam is caused by a dirty photoeye will find evidence for the dirty photoeye and ignore the rising drive current that points to a worn bearing. The playbook should require the observer to state at least one alternative hypothesis for each trigger. The second error is short sampling. A five-second observation window can miss a fault that repeats every two minutes. The evidence capture instructions in the playbook must define a minimum observation duration for each trigger type. The third error is ignoring the start-up context. A drive current reading in the first fifteen ## Related Pearl Gateway Guides - [Condition Monitoring: Data Signals and Condition Monitoring](/docs/condition-monitoring-data-signals-and-condition-monitoring/) - [Repeat-Fault Elimination: Data Signals and Condition Monitoring](/docs/repeat-fault-elimination-data-signals-and-condition-monitoring/) - [Maintenance Shift Handover: Data Signals and Condition Monitoring](/docs/maintenance-shift-handover-data-signals-and-condition-monitoring/) ## Site-Specific Review Worksheet This educational worksheet supports a structured review of condition monitoring: shift-level diagnostic playbook. Begin by identifying the equipment boundary, control ownership, operating modes, material characteristics, upstream dependencies and downstream consequences. Record what the system is expected to do, what was actually observed and which evidence is time-aligned. Avoid changing several variables at once, because simultaneous changes make cause and effect difficult to establish. ### Evidence to collect - Operating mode, active mission or route, and the exact sequence state. - Alarm history, device state changes and controller timestamps. - Physical observations such as alignment, contamination, wear, obstruction and load condition. - Recent maintenance, software changes, parameter changes and recurring work orders. - Upstream and downstream readiness, including blocked, starved and unavailable conditions. ### Decision boundaries Use approved site procedures and competent engineering judgment before intervention. General information in the Maintenance & Reliability library cannot determine whether a specific machine is safe to enter, restart or modify. Preserve original settings, document authorized adjustments and establish a rollback point before controlled testing. When evidence conflicts, stop and resolve the timestamp, naming or measurement discrepancy before drawing a conclusion. ### Closeout record A useful closeout record states the symptom, confirmed cause, evidence, corrective action, validation method, residual risk and follow-up owner. It should also identify whether the event exposed a design weakness, maintenance gap, training issue, spare-parts issue or monitoring blind spot. This turns a single recovery into reusable reliability knowledge without treating one observation as universal. ## Evidence Matrix for Operational Review Evidence group | Questions to answer | Why it matters Sequence state | What mode, step, mission and interlock state were active? | Separates a physical problem from an expected control hold. Material condition | Were load dimensions, orientation, stability and spacing within the intended envelope? | Explains faults that appear random when only controller data is reviewed. Device evidence | Which inputs changed, in what order, and against which timestamp? | Supports repeatable diagnosis instead of component substitution by guesswork. Change history | What maintenance, configuration, software or process change preceded the symptom? | Helps define a useful comparison window and rollback boundary. For condition monitoring: shift-level diagnostic playbook, the matrix should be completed with evidence from the same event window. Mixing observations from unrelated shifts can create a convincing but false causal story. If timestamps are inconsistent, establish which controller, server or operator record is authoritative before comparing event order. Trend evidence is more useful when the measurement definition remains stable. Record units, sampling interval, filtering, equipment mode and product family. A rising fault count may reflect increased throughput rather than deteriorating equipment, while a stable count can hide deterioration if production volume has fallen.