How much data do I need for predictive maintenance?

Events and coverage, not rows

A million rows do not teach a model much about failures if only two failures are among them. When judging data volume, two questions matter more: how many failure or maintenance events are recorded, and do they cover the conditions the machine runs under, including low and high load, different speeds and product changes?

If all the failures happened under one operating condition, the model learns that condition and little else, and a large row count can hide this. Sampling must also be consistent: the same sensors, at the same rate, with trustworthy timestamps. Irregular or gap-filled records shrink the usable data without any warning.

Hypothetical count

Suppose a plant has 50 pumps, each logged hourly for two years.

• Row count: 50 × 2 × 8 760 = 876 000 hourly rows.
• Failure count: the logs hold only 2 failures in those two years.

So the table has 876 000 rows but only 2 failure events, about 438 000 rows per failure. If one failure happened at high load and one at low load, a remaining useful life (RUL) model still has too few failure histories to learn the degradation path. The row count looks large; the event count does not.

What to start with, and common mistakes

Start with the data you have. Condition thresholds on a single measurement, such as a vibration level checked against the machine’s own baseline, need little history. Anomaly detection, as described in the other questions here, needs a clean normal period. Remaining useful life models need run-to-failure histories and a defined failure threshold, which many plants do not yet have.

Common mistakes include confusing row count with evidence, mixing maintenance records with undated entries, and assuming public data stands in for your own. The Case Western Reserve University Bearing Data Center offers bearing measurements for practice. It helps test methods, but it does not replace the history of your own machines.

Follow-up questions