How To Maintain Machine Health

Purpose:

Equip teams with a structured approach to identify, act on,and prevent machine health issues before they become costly downtime events —using the machine insights already available in Caddis.

“Before we had Caddis, we were just taking people’s word for it… that it was fixed.”
— President, Aluminum Manufacturer

Outcomes:

• Detect abnormal machine behavior earlier
• Convert repeated failures into preventive tasks
• Use runtime-based triggers for smarter PM scheduling
• Create a continuous improvement loop for asset care

Tools You’ll Use in Caddis:

• Machine state history
• Sensor-based alerts
• Run-hour data to schedule alarms
• Notes and PM tracking features
• Shift performance trends and runtime comparison

Timeline:

Ongoing, with weekly checks and monthly review loops

Who’s Involved:

Role

• Maintenance Lead
  
  • Sets PM strategy, monitors alerts
• Caddis Champion
  
  • Tracks run hours, configures alerts
• Operators
  
  • Report abnormalities or symptoms
• Engineering
  
  • Helps with root cause + redesigns
• Production Manager
  
  • Ensures follow-through on fixes

Step-by-Step Execution

Step 1: Identify Health Signals That Matter

What data can tell you a machine is becoming “unhealthy”?

Common signals

• Vibration exceeds a set threshold
• Runtime crosses X hours since last PM
• Too many short stops occur in a shift
• Temperature stays above normal for more than 5 minutes

Start with just 1–2 of these per machine to keep things focused.

Step 2: Configure Alerts or Triggers in Caddis

Use the alarm system to notify the right people when:

• Vibration  exceeds a set threshold
• Runtime  crosses X hours since last PM
• Too many short stops occur in a shift
• Temperature  stays above normal for more than 5 mins

Assign owners to each alarm:

• Example: “Vibration alert on press #2 = Matt (Maintenance)”
• Set preferred notification method (email, app alert)

Step 3: Create Runtime-Based PM Schedules

Instead of monthly calendar-based PMs, switch to:

• “Every 100 run-hours” or
• “Every 25 tool changes” (if tracked)

Use Caddis run time logs to:

• Forecast when the next PM is due
• Trigger reminders or maintenance tasks

This improves accuracy and reduces over-maintaining.

Step 4: Track Trends and Investigate Root Causes

When a failure happens, document it and ask:

• "Was there a warning in the data"
• "How long had the issue been trending"
• "Is this the second or third time this happened?"

Log notes on downtime or repair events inside Caddis, and start a pattern log.

Step 5: Add a PM to Prevent Future Failures

Use findings to create new PM tasks

• “Check bearing every 100 hous” (if vibration spike preceded failure)
• “Flush coolant every 200 hourd” (if overheating preceded shutdown)

Include:

• Trigger condition (runtime, operator check, sensor alert)
• Responsible party
• Expected time to complete
• Completion feedback loop (add a note when done)

Step 6: Build a Monthly ‘Machine Health Review’

Duration: 45 minutes
Attendees: Maintenance, CI, Production, Caddis Champion

Agenda:

1. Review previous month’s top downtime drivers
2. Look at health alerts triggered by Caddis
3. Spot machines with repeated failures
4. Decide 1-2 new PMs to add
5. Validate effectiveness of past PM changes

Metrics to Track:

• PM completion rate
• > 95% on-time
• Alerts triggered vs. acted on
• 100% action within 24 hours
• Repeat failures per machine
• Decreasing trend
• Downtime hours avoided
• Quantified month-to-month

Clarifying Notes and Tag Use

• Tags in Caddis are not applied to failure events or sensor alerts directly.
• However, notes can be logged on completed PMs and downtime reasons.
• These notes help correlate machine behavior to operator, part, or job —     especially if those were tagged during active runs.

You’re not tagging the interruption, but you can relate it back to a specific tagged production run.

Common Challenges (and Solutions)

• “No one sees the alerts”
  
  • Assign alert owners + make alarm monitoring part of shift  startup
• “We keep fixing the same thing”
  
  • Use 5 Why’s to build a PM instead of another repair
• “We have too many PMs now”
  
  • Audit which ones are based on usage vs. calendar time

What Success Looks Like:

• PMs are timely, data-driven, and based on real usage
• Teams see issues coming before the machine breaks
• Downtime is reduced — and when it happens, it’s not a surprise
• A new failure automatically leads to a new preventive action