From Data to Decisions: Visualising Instrument Utilisation and Reliability Across Modern Laboratories

Abstract

Analytical laboratories across pharma, life sciences, food, agriculture, and water quality manage growing fleets of chromatography systems alongside other instruments. Planning, reliability, and capacity decisions depend increasingly on integrated data from Chromatography Data Systems (CDS) together with Laboratory Information Management Systems (LIMS), Electronic Laboratory Notebooks (ELN), and/or Computerised Maintenance Management Systems. This article explores practical visualisation patterns that convert disparate logs into timely, decision-ready information for lab technicians, managers, equipment engineers, and lab IT. Examples include downtime analysis, reliability trends, capacity versus backlog and throughput view. Every example is constructed using common analytics tools and can be used with the software stack of your choice. (Power BI, Tableau, Shiny, Dash, Spotfire).

Introduction

Modern analytical laboratories generate large volumes of data every day. Chromatography Data Systems (CDS) record sequences, audit trails, and instrument events. Laboratory Information Management Systems (LIMS) and Electronic Laboratory Notebooks (ELN) platforms add sample and workflow information. Maintenance systems capture service and repair history. Although each system fulfils its own purpose, the information often stays separate. As a result, it can be challenging for laboratory staff and managers to see how instruments’ performance, reliability and workload fit together.

Analytical laboratories nowadays run dozens to well over one hundred instruments across Research & Development (R&D) and Quality Control (QC). Chromatography systems remain the backbone for testing drug substances, drug products, raw materials, and in-process controls. Sector data shows that pharma continues to drive instrument market growth, in parallel with rising expectations for automation and software integration [1]. Laboratories are therefore shifting from local, manual reporting to consolidated dashboards that connect multiple systems. Earlier articles showed how to collect utilisation information from vendor-specific data containers and unify them for faster decision-making [2, 3].

When data from CDS, LIMS, ELN and other platforms is brought together, it becomes possible to look beyond individual events or instrument records and gain a broader view of how the laboratory and its instruments operate. Integrated data allows teams to compare instrument reliability, plan capacity against sample backlog, and reduce investigation time for errors and deviations. Independent industry analyses have shown that digital QC and online testing approaches can substantially cut investigation workload and help address recurring deviations [4]. This article expands on that idea with practical visualisation patterns and example figures.

This article presents a limited set of visualisations that can be created from the types of data typically available in CDS, LIMS, ELN and maintenance systems. All figures were generated using simulated datasets that mimic real laboratory behaviour. The plots themselves were created in R using the {ggplot2} package, made interactive with {plotly} and displayed within a {shiny} dashboard. The examples don't rely on specific system architecture and are intended to point out what is achievable when these data sources are combined.

Data foundations

The visualisations here assume a minimal, vendor-agnostic schema:

Sequences and acquisitions from CDS (start/stop timestamps, method, injections, status)
Instrument audit trail or activity log (event type, severity, timestamp, message)
Instrument metadata (vendor, model, lab, install date, maintenance date, status)
LIMS/ELN context where available (sample type, project priority)
Optional maintenance/CMMS events (ticket created/ticket resolved) to refine downtime measurement.

These streams allow you to calculate common KPIs such as utilisation by hour or day, percentage of failed runs, time between errors, estimated downtime, and scenario-ready capacity metrics.

What to visualise and why

Operational overview for situational awareness

Start with a compact status overview that a shift lead or lab manager can scan in seconds. A structured table can show instrument status, next maintenance date, days remaining and last sequence details [Figure 1]. Grouping by lab or team makes handovers and standups more effective.

Figure 1. Status overview of chromatography instruments. The interactive table highlights status, last and next maintenance dates, estimated days to capacity, and last run details. Expanding a row reveals module‑level wear indicators and the most recent sequence result.

The table in Figure 1 shows the status of each instrument in the lab. It summarises key information such as whether the instrument is available or under maintenance. It shows when the last maintenance was performed and indicates how much ‘lifetime’ is left based on the usage since the last maintenance. The rows are expandable (shown in the orange-lined area), where more details are shown, such as module information and information on the last run. This can help teams understand which instruments are ready for use and which may need attention.

Downtime and recurring failures

To reduce lost analysis time, teams need to know which errors recur and where outages accumulate. Two complementary views work well together:

A Pareto chart to identify the most frequent error types [Figure 2].
A stacked downtime bar to show how error types contribute to total downtime per instrument [Figure 3].

Figure 2 ranks the errors by how often they occur and splits them over the different instruments. The chart helps to quickly show which issues happen most often and if they occur more on specific instruments. On the other hand, certain errors might occur often but have minimal impact on instrument uptime; this is visualised in Figure 3, where the total hours of downtime over a certain period are visualised in a stacked bar chart and split over the different error types. The most frequent instrument error does not cause the most instrument downtime. These charts help teams to focus on resolving recurring issues by focusing on the most recurring and impactful error types.

If your maintenance data is not yet integrated, a practical estimate for downtime is the interval from the error timestamp to the next sequence start on the same instrument. When CMMS data is available, refine the measure into detection delay, repair time, and recovery, which supports more precise mean time to repair (MTTR) analysis.

Figure 2. Pareto chart of instrument error types ranked by frequency, based on audit trail entries. This view focuses attention on error categories that drive most events and are therefore most promising to address first.

Figure 3. Total downtime per instrument, broken down by error type. This complements the Pareto by revealing where a less frequent error may still cause significant hours lost on a specific instrument.

Relationships between downtime, instruments, and error categories

Sankey diagrams help readers trace how downtime clusters by category and where it lands [Figure 4]. The diagram shows how problems flow through the system. The downtime is divided into four categories: short, medium, long, and extraordinarily long downtime. The error types are in the centre and on the instruments on the right. The width of the band stands for how often each combination occurs. It helps to see which downtime category can be attributed to which errors and which systems are affected most often.

Sankey links are aggregated flows. If you prefer more technical precision, place a bar chart summarising the same buckets below the Sankey for cross‑checking.

Figure 4. Sankey linking downtime buckets to instruments and error families. The diagram reveals which combinations dominate and where intervention is likely to pay off.

Reliability patterns: time between errors

A distribution view of time between errors complements frequency‑based plots by focusing on stability, not just count [Figure 5]. The ‘violin’ plot shows how much time typically passes between errors for each instrument. The wider parts of the ‘violin’ show a higher occurrence of that time between errors. While a narrow shape means that the time between errors occurs less often. A higher position means longer time between errors, which is better. The key message of the visualisation is simple: instruments with higher and more compact shapes tend to be more reliable. In the example, INST_007 clearly outperforms the other 3 instruments, which are all positioned lower and show more variation in the time between errors.

This is helpful during vendor discussions or when deciding which instruments are safe to load with critical batches.

Figure 5. Violin plots of time between errors per instrument. Wider violins indicate higher variability. The height and the width of the violins help identify stable workhorses versus problematic systems.

Utilisation patterns over days and weeks

Heatmaps communicate briefly when capacity is under pressure. With acquisition timestamps rounded to the hour, you can compute a “percentage of hour used” metric and display it per day per instrument [Figure 6]. The heatmap shows how busy each instrument was during each hour over a defined period. It gives a quick overview of peak hours, quiet hours, and patterns such as weekends.

This same view can be aggregated to weekdays to uncover recurring weekly rhythms or to months for seasonal trends. Such visualisations help with scheduling analysis and planning maintenance.

Figure 6. Two-week heatmap of hourly utilisation per instrument. Darker cells indicate a higher fraction of the hour used. Patterns reveal peak periods, weekend usage, and silent hours suitable for maintenance.

Throughput quality: failed and aborted runs

Utilisation without quality can be misleading. A simple stacked percentage chart shows aborted plus failed shares per instrument and spotlights where methods or modules need attention [Figure 7]. The chart shows the percentage of runs which are either aborted or failed due to an instrument error. Instruments with a higher percentage of failed runs may need attention. A similar plot can be used to compare methods instead of instruments to check if particular methods cause regular failures.

Figure 7. Percentage of aborted and failed runs per instrument. Systems with consistently higher rates call for deeper review of methods, consumables, or maintenance.

Method and runtime diversity

Different instruments often host different method portfolios. A ridge or density plot of sequence runtime per instrument helps explain why workload splits the way it does [Figure 8]. Each instrument has its own curve showing which run durations must often occur. It helps explain differences in why certain instruments have more remaining capacity than others. For example, when one instrument is used mainly for short assays and another for long related substance runs. It also highlights if an instrument is used for a method that is unusual compared to others.

Figure 8. Each ridgeline shows how long sequences typically run on a given system, highlighting variability and skew, e.g., short vs. long methods. This visualisation could support decisions on load balancing and capacity planning.

Implementation notes (tools and governance)

These views can be built in most analytics stacks. Choose technology based on where and how users will use the dashboards and the need for complex and custom visualisations:

Enterprise BI: Power BI or Tableau for quick and standardised dashboards, user-friendly and robust data connectivity.

Technical deep dives: Shiny or Dash for in-depth analytics, advanced visuals, and high flexibility.

Regardless of the front end, success depends on reliable data engineering. Extract data through vendor APIs or databases, stage it in a harmonised schema and version it so that business rules can be confirmed. If your lab operates under GxP, apply change control to data transformations and keep lineage so visual outputs stay auditable. Practical refresh intervals range from near real‑time to scheduled batch updates, depending on infrastructure and system load tolerance.

Discussion

All figures shown can be generated with either simulated or production data. Synthetic datasets are useful for design and stakeholder discussions, but visual conclusions should only guide decisions when sourced from validated, production pipelines. When connecting live systems, align stakeholders on three points:

Availability and source: where each field originates and how often it refreshes.
Definitions: what counts as a failure, when downtime starts and stops, and how utilisation is calculated.
Validation: checks that confirm mappings and calculations are correct, especially when fusing data across CDS, LIMS/ELN and other platforms.

Without clear definitions and governance, visualisations can mislead. With them, teams can standardise language and accelerate routine conversations about reliability, capacity, and scheduling. Industry reporting indicates that labs investing in digital QC, data integration and fit‑for‑purpose analytics reduce investigation effort and improve cycle time [1, 2].

Conclusion and next steps

Laboratories face predictable questions each week: Which instruments are stable, where is capacity constrained, which errors cost the most time, and how should workloads be scheduled? The visual patterns in this article offer a practical way to answer them with data that most labs already collect. An integrated dashboard that blends CDS acquisitions, audit events, LIMS/ELN context and maintenance information helps teams detect risks early, shorten investigations and schedule more confidently.

If you would like to explore what is possible for your laboratory, your workflows, and your current technology stack, we would be happy to schedule a conversation. Every organisation has a different combination of CDS, LIMS/ELN and maintenance systems, and each environment comes with its own constraints and opportunities. We can help review options, discuss approaches, and guide you in finding which visualisations or integrations could bring the most value in your specific context.

References

[1] LCGC Europe. Analytical Instrument Vendors: Q2 2025—Pharma/Chemical Growth (Sep 2025).

[2] McKinsey & Company. Digitization, automation, and online testing: The future of pharma quality control (2019).

[3] wega Informatik. Determine Chromatography Instrument Utilization in Real Time.

[4] wega Informatik. Determine Chromatography Instrument Utilization in Real Time (Part 2).