Real-time KPIs in manufacturing are performance indicators computed continuously from source data, machine signals and station entries, so the number on the screen describes the line as it runs now, not as it ran yesterday. A KPI is real-time when someone can still act on it before the shift ends.

Most plants do not lack KPIs. They lack KPIs that arrive in time to matter. The same metric, availability, count against plan, first pass yield, is a different tool at different speeds: live, it steers the shift; daily, it explains the shift; monthly, it decorates a slide. This post covers which KPIs are worth the effort of making real-time, what "real-time" has to mean in practice, and the steps to get a KPI from spreadsheet speed to shift speed. For the full catalog of metrics and how to choose among them, start with manufacturing KPIs.

What makes a KPI real-time?

Three properties, and all of them are necessary.

Source capture. The inputs come straight from the event: a machine signal, a sensor, a one-tap entry at the station. If the number passes through a clipboard and a retype, it is a report wearing a dashboard costume. Capturing once at the source is the same discipline behind a single source of truth.

Continuous computation. The KPI recalculates as events arrive, not when someone runs the report. Availability that updates at each stop and start is real-time; availability computed every Friday from the same events is history.

Time left to act. This is the property people forget. A KPI is only meaningfully real-time if it reaches someone who can still change the outcome, an operator who can clear the jam, a supervisor who can rebalance the line. A live number nobody is assigned to act on is just faster wallpaper.

Which KPIs are worth tracking in real time?

The ones that decay fastest. A useful way to sort your KPI list is by how quickly the number loses its power to change anything.

Act-within-minutes KPIs: line status and active downtime, count against plan or takt, and cycle time on the constraint. These exist to trigger immediate response, and stale versions are nearly worthless; a downtime figure you learn tomorrow is an obituary, as covered in real-time downtime visibility.

Act-within-the-shift KPIs: running OEE or availability, first pass yield by station, scrap count, and schedule adherence by order. Live versions let a supervisor rebalance, swap a die, or call maintenance while the shift can still be saved. Per-shift OEE tracking is the natural grain here.

Daily-and-slower KPIs: inventory turns, maintenance cost, absenteeism, TRIR. These aggregate slowly and drive planning decisions, not floor decisions. Making them tick every second adds cost and noise without adding a single better decision. Honest answer: most KPIs belong in this band, and that is fine.

The KPI decay spectrum How fast does the number go stale? MINUTES line status active downtime count vs takt SHIFT running OEE first pass yield schedule adherence DAY scrap summary maintenance backlog MONTH inventory turns TRIR, cost KPIs Spend your real-time effort here, on the left two bands. The right two bands are fine at report speed. Most KPIs live there.
Sort KPIs by how fast they decay. Real-time investment belongs where the number dies within a shift.

A related sorting question is leading versus lagging. Real-time treatment turns some lagging indicators into leading ones: scrap counted at the station as it happens is a warning you can act on, while the same scrap totaled next week is an explanation you can only file. The metrics that gain the most from speed are the ones where an early signal changes behavior, cycle time creeping up on a bottleneck, yield sagging on one station, a line drifting behind takt. If seeing the number sooner would not change what anyone does, speed adds nothing, and that question is the cheapest filter you can run before building any pipeline.

What does a real-time KPI pipeline look like?

Every live KPI is the end of a short pipeline, and each stage has a latency budget. The event happens: a cycle completes, a machine stops, a check fails. The event becomes a record, from a PLC signal or a station tap, within seconds. The KPI recomputes from the new record, within seconds more. The display and any alert update, so the person assigned to the number sees it move. Total budget from event to eyeball: under a minute for the minutes-band KPIs, a few minutes for the shift band.

Two failure points account for most broken pipelines. The first is manual capture, which inserts an hours-long pause at stage one and quietly converts the live KPI back into a report; the difference is measured in manual vs automated OEE tracking. The second is definition drift: if the KPI on the screen is computed differently from the KPI in the monthly review, the plant argues instead of acting. Fix it by writing definitions once, ideally borrowed from the standard: ISO 22400-2 defines 34 KPIs for manufacturing operations management, including availability, throughput rate, and the OEE index, exactly so a KPI means one thing at every speed. With roughly 12.7 million people working in U.S. manufacturing per the Bureau of Labor Statistics, the KPI screens on plant floors are read by more people than almost any other business reporting, and they deserve the same rigor.

From event to action: the live KPI pipeline Event to action, with a latency budget event on the floor record seconds recompute seconds display + alert seconds named person acts, minutes manual retype here adds hours If no one is named at the last stage, the pipeline ends at wallpaper.
Every live KPI is a pipeline with a latency budget. Manual capture and unowned alerts are where budgets die.

How do you make a KPI real-time?

One KPI at a time, pipeline first, screen last.

  1. Choose a minutes-band or shift-band KPI that already hurts. Downtime on the constraint and count vs plan are the usual first picks; they pay back fastest.
  2. Write the definition down. Formula, data sources, boundaries, borrowed from ISO 22400 or your own OEE calculation standard, and get production and finance to initial it.
  3. Automate the capture. Machine signal where possible, one-tap station entry where not. This step is the project; everything after it is configuration.
  4. Compute continuously and display where the action is. The line's screen and the responsible person's phone, not just a manager's browser tab.
  5. Attach an owner and a trigger. Name who responds when the KPI crosses its threshold and what they do. A live KPI without an owner is the most common failure in the whole genre.
  6. Reconcile weekly against the official reports. The live number and the reported number must match or converge with an explanation, or trust erodes and shadow spreadsheets return.

Then, and only then, add the next KPI. Plants that light up twelve live tiles in week one usually own twelve unowned numbers by week six.

How does Harmony AI handle real-time KPIs?

Harmony AI is an AI-native MES, and live KPIs are what its dashboards are made of rather than a module bolted on. Machine signals, station entries, and the systems you already run feed one live model, so a KPI like OEE is computed from the source, from actual cycles and actual stops, not estimated from an end-of-shift summary. The same number appears on the operator's screen, the supervisor's phone, and the leadership rollup, which ends the definition-drift argument by construction. And because the layer is AI-native, the KPI comes with its receipts: ask why availability dropped and you get the stops behind the number, cited, not just a red tile.

We are honest about the boundary: a live KPI shortens the path from event to decision, and that is all it does. The decision, the fix, and the follow-through still belong to your team. If you want to see the pipeline running on a real floor, the CLS case study shows it, our OEE calculator lets you baseline today's numbers by hand first, and real-time OEE visibility goes deeper on the flagship metric of this whole family.