Real-time reporting means a metric updates, and raises an alert if needed, seconds or a few minutes after the event behind it happens. Not every report has to be live: a machine stoppage, a stock threshold or a late shipment needs immediate data because someone must act now; monthly profitability does not.
"The report arrived this morning; the problem started yesterday lunchtime"
In many businesses the daily report is produced by an overnight query, or by someone merging spreadsheets first thing in the morning. At nine o'clock a manager looks at yesterday's table. Only then do they learn that a line slowed down yesterday afternoon, a customer order sat in the warehouse, or a critical material fell below its reorder point. The hours when intervention mattered most have already gone.
The opposite mistake is just as common. In the name of "make everything live", a monthly finance report becomes a panel that refreshes every minute. The source system strains, figures move around during the day and nobody knows which number to trust. So the first rule of real-time reporting is this: choose the decision first, then the speed of the data. For finance indicators such as the cash position, a daily refresh is usually enough; we show how to set that up in cash flow reporting automation.
We covered where spreadsheet reporting breaks down in moving from Excel reports to BI, and the basics of bringing metrics onto one screen in our management dashboard (BI) guide. This article is about which parts of that dashboard genuinely need to be live.
What late data costs
In Türkiye, reporting infrastructure varies hugely with company size:
According to TurkStat, in 2025 ERP, CRM and business intelligence (BI) software were used by 76.5%, 42.0% and 35.1% respectively of enterprises with 250 or more employees, but by only 23.6%, 9.9% and 4.9% of those with 10 to 49 employees. (TurkStat ICT Usage in Enterprises Survey 2025)
In other words, fewer than one in twenty firms with 10 to 49 employees uses BI software; at that size, live reporting is not yet on the agenda for most businesses. The cost shows most clearly in manufacturing. According to Siemens' The True Cost of Downtime 2024, large plants average 25 unplanned downtime incidents a month and lose 27 hours of production a month. A team that finds out about a stoppage in the next morning's report can mostly just record the loss.
The time cost of finding information piles up in the office too. Atlassian's State of Teams 2025 survey of 12,000 knowledge workers and 200 executives found that teams waste 25% of their time just searching for answers. Answering "where is that order?" by phone, email or by looking over someone's shoulder turns into hours a job that a well-built live indicator does in seconds.
Does every report need real-time reporting?
No. The right question is: "When the person looking at this metric sees the result, how quickly can they act?" If the response time is minutes, the data must arrive within minutes; if action happens in a weekly meeting, daily data is enough.
| Latency tier | Typical delay | Example use | Typical data source |
|---|---|---|---|
| Real time | Seconds | Machine stoppage, alarms, door and access events | PLC, sensors, event stream |
| Near real time | 1–15 minutes | Order status, stock threshold, shipment tracking | ERP/WMS change log, API |
| Intraday | Hourly | Sales performance, call-centre load | Scheduled data transfer |
| Periodic | Daily / weekly | Profitability, budget, KPI scorecard | Data warehouse |
The boundaries are not rigid, but the distinction drives cost. Second-by-second data needs streaming infrastructure and always-on connections, and sensor readings typically land in a time-series database. Daily data can be produced cheaply and robustly by an overnight data warehouse and ETL process. In most businesses the right architecture is a mix of the two.
In logistics, for example, vehicle location and delivery status are tracked in near real time, and we explain how that data feeds the next day's plan in route optimisation. Retail has a similar split: store stock and checkout queues are watched in near real time, while category profitability and supplier performance make more sense in a weekly report. Which metrics a sales team should watch during the day and which weekly is covered in sales dashboard metrics.
A six-step framework for real-time reporting
- Write down the decision and the decision-maker. For example: "If Line 3 is down for more than five minutes, the shift supervisor and maintenance lead are notified." No decision, no need for live data. Use the criteria in how to set KPIs when choosing metrics.
- Set the acceptable delay. For each metric, answer "how many minutes old can this be, at most?" That number chooses the technical architecture for you.
- Listen to the source as close to the event as possible. Machine data comes from the PLC or a sensor, business data from the change log in the ERP or WMS, and external systems through an API. Receiving a notification when something changes, rather than polling the source every minute, spares the source system unnecessary load. We compare the integration options in API integration explained.
- Fix the definition. On the live panel, what exactly counts as "downtime", a "late order" or "critical stock"? If the definition differs from the overnight report, the two will disagree and trust disappears. Our data governance framework guide covers how definitions get owned.
- Show the exception, not the wall of numbers. A live screen that is mostly green is normal; the value lies in the alert that reaches the right person when a threshold is crossed. Instead of fixed thresholds you can also use anomaly detection to catch unexpected deviations. Finding the cause once the alert fires is the job of root cause analysis with manufacturing data.
- Monitor latency and outages. When a data feed stops, the panel keeps showing the last number and nobody notices. Every metric should carry a "last updated" time, and a feed that goes quiet for too long should itself raise an alert.
Real-time reporting on the shop floor
In a factory the most common live needs are stoppage, speed and quality data. When that data comes straight from the machine, OEE can be seen without waiting for the end of the shift. Even older machines can do this with added sensors and data collection devices. Ways to bring scattered field devices onto one screen are covered in our remote monitoring and IoT platform guide.
Five common mistakes
Live reporting projects usually disappoint because of design decisions rather than technology. These are the mistakes we see most often:
- Making every metric live. When forty metrics refresh every second, the screen never stops moving and the change that matters gets missed. Keep live metrics few and deliberate; leave the rest in periodic reports.
- Sending every alert to everyone. When each threshold breach emails the whole management team, nobody reads them within a week. Each alert needs one owner, one channel and a repeat rule.
- Setting thresholds once and forgetting them. In processes that change with season, shift or product mix, a fixed threshold either fires constantly or never. Tune thresholds against real data in the first months.
- Building the panel before fixing data entry. If order status is entered late on the floor, the fastest infrastructure will still show late data. Sometimes the fix is at the point of capture: a handheld terminal, a barcode scan or an automatic count from the machine.
- Forgetting mobile access. Shift supervisors and field leads are not at a desk. An alert that lands on a phone and opens the detail in one tap is what turns live reporting into action.
How we do this at Digital Bridge
We build live reporting as a chain that runs from the source system to the alert, not as a display screen:
- Discovery and requirements analysis. With the decision-makers, we list which decision needs data at which speed. We write down an acceptable delay for each metric and weed out requests for "liveness" that nobody will act on.
- Sources and integration. We take ERP, WMS, CRM and machine data through API integration and change logs. Where disconnected systems have to work as one process, we build integrated systems; on the production side we collect line data through MES production management.
- A two-speed architecture. Live metrics are fed from a streaming layer, while historical comparison and periodic reports come from a data warehouse. Using the same definition in both layers stops the "why does the live figure differ from month end?" question before it starts.
- Pilot, then roll-out. We usually start with a single line, warehouse or process. During the pilot we measure whether alerts actually turn into action, then widen the scope. The final layer turns metrics into role-based screens on a BI dashboard.
We apply the same principle in our own products. In the SmartPass access control system, door events are monitored live, and in an emergency the list of who is on site right now is available instantly by zone; here seconds genuinely matter. The attendance report in the same system is produced periodically against the shift plan. It is a good example of matching each dataset to the speed it actually needs.
Your next step
Start with a simple table: list the five metrics you track today, and next to each note how late it arrives now and how many minutes old it should be at most. The metric with the biggest gap is your first pilot. Send us that list through our contact page; we will review your source systems and propose the architecture and scope in writing. More guides on the subject are on our Data & Analytics hub.