InfluxData Blog

What’s New in InfluxDB 3.9: More Operational Control and a New Performance Preview

Peter Barnett (InfluxData) — Thu, 02 Apr 2026 12:00:00 +0000

We’ve spent the last few months listening to how teams are running InfluxDB 3 in the wild. The feedback was clear: as you scale, you need less “guesswork” and more control. Today’s release of InfluxDB 3.9 is our answer to that.

As more teams move InfluxDB 3 into production, our focus has shifted toward the operational experience: how you manage the database at scale, how you ensure it remains secure, and how you provide a seamless experience for users. This release is packed with a host of quality-of-life improvements and a beta of the key features we have planned for upcoming releases.

Whether you’re using the open source InfluxDB 3 Core for recent data and local workloads or scaling with InfluxDB 3 Enterprise for the full clustering and security suite, these 3.9 updates are designed to make your stack more predictable.

Operational maturity and system transparency

In 3.9, we’ve focused on making the database more predictable and transparent for operators. We have organized these refinements into three key areas:

Advanced CLI & Automation: We’ve expanded the CLI to better support complex, headless environments. This includes new flags for non-interactive automation and data validation, alongside support for unique host overrides to target specific node types in a cluster. We’ve also improved how Parquet query outputs are piped, making it easier to integrate InfluxDB into automated data pipelines.
System Reliability & Resource Management: We’ve refined how the database handles resources and large-scale schemas. To better support complex data, we’ve increased the default string field limit to 1MB. We’ve also hardened the database lifecycle; administrative controls are now more rigorous, and we’ve ensured that background resources, such as triggers, are cleanly decommissioned whenever a database is removed.
Visibility & Under-the-Hood Infrastructure: We’ve upgraded our core infrastructure to improve both security and operational clarity. This includes upgrading DataFusion and the bundled Python for more efficient query execution and plugin security. Additionally, the system now provides better visibility into access control and product identity, updating metrics, headers, and metadata access to clearly distinguish between Core and Enterprise builds across your stack.

Collectively, these refinements remove the subtle points of friction that can accumulate as a system scales in production. By hardening resource management and streamlining automation, we’re ensuring that InfluxDB 3 remains a predictable, “set-it-and-forget-it” core for your infrastructure.

Now in beta: A new performance preview

Behind the scenes, we’ve been working on performance updates to InfluxDB 3. These improvements support large-scale time series workloads without sacrificing predictability or operational simplicity. This work lays the foundation for what’s coming in 3.10 and 3.11, specifically focusing on smoothing behavior under load and expanding the range of schemas InfluxDB 3 can handle.

Because performance in time series is highly dependent on specific workloads and cardinality, we are introducing these updates as a beta in InfluxDB 3 Enterprise. The beta is intended for testing in staging or development environments only. It allows you to explore and provide feedback on:

Optimized single-series queries: Targeting reduced latency when fetching single-series data over long time windows.
Resource smoothing: Testing reduced CPU and memory spikes during heavy compaction or ingestion bursts.
Wide-and-sparse table support: For handling schemas ranging from extreme column counts to ultra-sparse data tables (or any combination).
Automatic distinct value caches: Early-stage, auto-creation of caches designed to reduce friction and eliminate metadata query latency.

These updates are available as an optional, flag-gated preview in InfluxDB 3.9 Enterprise. They are not recommended for production workloads. We encourage Enterprise users to test these capabilities against their specific use cases to help us refine the features for GA. InfluxDB 3 Core will also support many of these new features in the coming releases.

For instructions on how to enable these preview flags and to view the full technical requirements, visit our official Enterprise documentation.

Download InfluxDB 3.9: Available now via our downloads page or latest Docker images.
Join the beta: If you are an InfluxDB 3 Enterprise Trial user, reach out to me in our Discord or Community Slack to learn how to enable these beta features.

What is MRO? Maintenance, Repair, and Operations Explained

Charles Mahler (InfluxData) — Tue, 31 Mar 2026 08:00:00 +0000

MRO stands for maintenance, repair, and operations. It refers to the activities, supplies, and services that keep equipment, facilities, and infrastructure running safely and efficiently. Every industry that relies on physical assets depends on MRO, whether that means replacing a worn bearing on a production line, restocking safety gloves in a warehouse, or servicing an HVAC system in a hospital.

Despite being one of the largest categories of indirect spending in most organizations, MRO is chronically under-managed. This article explains what MRO covers, why it matters, how maintenance strategies differ, and how it plays out across industries.

What is MRO?

MRO is a broad category that encompasses the indirect materials, maintenance activities, and operational support required to keep a business functioning. MRO includes everything from spare parts and lubricants to safety equipment, cleaning supplies, and the labor required to inspect, fix, and service physical assets.

The scope of MRO varies by organization, but it always sits outside of direct production. A replacement motor for a conveyor belt is an MRO item. The raw steel that travels on that conveyor is not. This distinction matters for accounting, procurement strategy, and inventory management.

Common MRO Supplies and Activities

MRO is easier to understand through concrete examples:

Category	Description	Examples
MRO supplies	Parts, materials, and consumables used to maintain equipment and facilities.	Spare parts (bearings, seals, belts, filters, motors), lubricants and greases, fasteners, hand and power tools, electrical components (fuses, contactors, wiring), safety equipment (gloves, goggles, hard hats, respirators), cleaning and janitorial products, adhesives and tapes, and facility consumables (light bulbs, HVAC filters).
MRO activities	Hands-on maintenance and repair work performed on assets.	Routine inspections, lubrication, electrical testing, equipment alignment, welding repairs, painting and corrosion protection, calibration, and full equipment rebuilds.
MRO services	Outsourced or contracted maintenance support.	Third-party maintenance contracts, on-call repair technicians, specialized inspections (non-destructive testing), and outsourced maintenance for complex assets.

Why MRO matters

MRO spending often accounts for a significant share of an organization’s operating costs, yet it receives a fraction of the strategic attention that direct materials get. The numbers make a compelling case for changing that.

The market is massive. The global MRO market was valued at roughly $715 billion in 2025 and is projected to grow steadily through the next decade, driven by aging infrastructure, the rise of predictive maintenance, and increasing demand for operational efficiency.
Downtime is extraordinarily expensive. A 2024 Siemens report found that unplanned downtime costs the world’s 500 largest companies a combined $1.4 trillion per year, roughly 11% of their annual revenues. At a facility level, costs vary by industry, but the averages are sobering: approximately $260,000 per hour in general manufacturing, and over $2 million per hour in automotive production. Even smaller manufacturers typically lose over $100,000 per hour of unexpected downtime.
Equipment failure is the leading cause of downtime. The average manufacturer faces an estimated 800 hours of equipment downtime annually. Equipment failure accounts for roughly 42% of unplanned downtime incidents, and base components like bearings, seals, and motors are the most common culprits. These are precisely the kinds of failures that a well-run MRO program is designed to prevent.
Proactive maintenance pays for itself. Research from McKinsey and others consistently shows that organizations implementing predictive maintenance programs see 18–25% reductions in overall maintenance costs and 30–50% reductions in unplanned downtime. The U.S. Department of Energy has reported a potential ROI of up to 10x on predictive maintenance investments. Reactive repairs, by contrast, cost three to five times more than planned maintenance once you account for emergency labor, expedited parts shipping, and cascading production losses.
Safety and compliance depend on it. Regulatory bodies across industries mandate specific maintenance activities and intervals. Falling behind on MRO creates safety hazards for workers, compliance risk for the organization, and potential legal liability.

Maintenance strategies: preventive, predictive, planned, and condition-based

Organizations typically employ a mix of strategies, and the trend across industries is a steady shift from reactive to proactive, data-driven approaches.

Preventive Maintenance

Preventive maintenance is scheduled work performed at fixed intervals to reduce the likelihood of failure. Oil changes every 500 operating hours, filter replacements every quarter, and belt inspections every month are all preventive activities. The advantage is predictability: you know what work is coming and can plan parts and labor accordingly. The drawback is that you may be replacing components that still have significant useful life remaining, which wastes money and materials.

Planned Maintenance

Planned maintenance is a broader category that includes any maintenance activity scheduled in advance, whether it follows a calendar-based interval, a usage-based trigger, or a condition-based alert. The defining characteristic is that the work is anticipated and resourced before it begins, as opposed to reactive or emergency maintenance. Planned maintenance also encompasses scheduled shutdowns and turnarounds, where equipment is taken offline deliberately for extensive servicing.

Condition-Based Maintenance

Condition-based maintenance (CBM) uses real-time monitoring of equipment health indicators like vibration, temperature, oil quality, and electrical signatures to trigger maintenance only when those indicators show that maintenance is actually needed. Rather than replacing a bearing on a fixed schedule, CBM replaces it when vibration analysis shows degradation has reached a threshold. This approach eliminates much of the waste inherent in time-based schedules while still catching problems before failure.

Predictive Maintenance

Predictive maintenance takes condition-based monitoring a step further by applying machine learning, statistical models, and trend analysis to forecast when a component is likely to fail. Where CBM reacts to current conditions, predictive maintenance anticipates future conditions based on patterns in historical and real-time data. Sensors tracking vibration, temperature, pressure, and acoustic signatures feed data into analytics platforms that can predict failures days or weeks in advance.

The results are striking: organizations with mature predictive maintenance programs report 35–45% reductions in unplanned downtime and an average ROI of around 250% within the first 18 months.

The movement from reactive to predictive maintenance is one of the defining trends in MRO. As IIoT sensors become cheaper and more accessible, even smaller manufacturers can begin shifting toward condition-based and predictive approaches.

MRO in manufacturing

In the manufacturing industry, MRO encompasses all indirect materials and maintenance activities required to keep a production facility running. It is everything that supports the production process without becoming part of the finished product.

Manufacturing MRO spending is often highly fragmented. A single plant might purchase thousands of distinct SKUs, such as motor drives, conveyor belts, lubricants, rags, and safety boots, from dozens of suppliers. The proportion of organizations using more than 250 MRO suppliers has grown from 6% to 15% in recent years. This fragmentation makes it difficult to negotiate volume discounts, track usage, or identify waste.

Common MRO priorities in manufacturing include reducing unplanned downtime on production lines, maintaining critical spares inventory for high-impact equipment, shifting from reactive to preventive or predictive maintenance, standardizing parts and suppliers to simplify procurement, and ensuring compliance with OSHA and environmental regulations.

Manufacturers that invest in structured MRO programs typically see improvements in overall equipment effectiveness (OEE), lower maintenance costs per unit of output, and fewer safety incidents.

MRO in aviation

Aviation has one of the most rigorous and regulated MRO environments of any industry. Aircraft MRO is governed by strict regulatory frameworks like the FAA in the United States and EASA in Europe. Every maintenance activity must be performed by certified repair stations, documented in detail, and traceable.

The four main categories of aviation MRO are airframe maintenance, engine maintenance, component maintenance, and line maintenance.

Aviation MRO is also where data-driven maintenance has seen some of its most advanced applications. Airlines use predictive maintenance platforms that analyze sensor data from aircraft systems to forecast component failures before they occur, minimizing aircraft-on-ground events and improving safety.

MRO in energy and utilities

Energy and utilities represent one of the most asset-intensive sectors for MRO. Power plants, refineries, pipelines, water treatment facilities, and electrical grids all require continuous maintenance to remain operational and safe.

The consequences of downtime in energy are particularly severe. Utilities face additional complexity from regulatory oversight and public safety requirements; a failed transformer or water treatment system affects entire communities.

This sector has been an early adopter of IIoT and predictive maintenance technologies. Real-time monitoring of turbines, generators, transformers, and pipeline infrastructure allows operators to detect degradation early and schedule maintenance during planned outages rather than responding to emergencies.

MRO procurement, inventory, and software

Three operational areas determine how well an MRO program actually performs on a day-to-day basis.

Area	Description and Key Strategies
Procurement	The process of sourcing and purchasing indirect materials. High transaction volume but low individual dollar value. Improvement strategies include consolidating suppliers, using blanket purchase orders, and implementing e-procurement platforms.
Inventory	Balancing part availability against carrying costs. Effective management relies on criticality-based stocking, min/max levels, and regular cycle counts. MRO inventory supports production but is not part of the finished product.
Software	Tools to plan, track, and optimize maintenance. Includes CMMS for work orders, EAM for lifecycle planning, and e-procurement tools to streamline purchasing.

The process of sourcing and purchasing indirect materials. High transaction volume but low individual dollar value. Improvement strategies include consolidating suppliers, using blanket purchase orders, and implementing e-procurement platforms.

Inventory

Balancing part availability against carrying costs. Effective management relies on criticality-based stocking, min/max levels, and regular cycle counts. MRO inventory supports production but is not part of the finished product.

Software

Tools to plan, track, and optimize maintenance. Includes CMMS for work orders, EAM for lifecycle planning, and e-procurement tools to streamline purchasing.

Where time series databases fit in an MRO strategy

The shift toward predictive maintenance creates a data infrastructure challenge that traditional systems were never designed to handle. A modern manufacturing facility with thousands of IIoT sensors can generate billions of data points daily. This is time series data, and it requires specialized tools at scale.

Traditional relational databases and legacy data historians struggle with the volume, velocity, and query patterns of high-frequency sensor data. Time series databases are built for this workload. They are designed to ingest large volumes of timestamped data at high speed, compress it efficiently for long-term storage, and support the kinds of queries that maintenance and operations teams actually need: trend analysis over time windows, anomaly detection, and correlation across multiple sensor streams.

InfluxDB is one of the most widely adopted time series databases in industrial environments. It is built to handle the data patterns that MRO and predictive maintenance generate, and it fits into the maintenance technology stack in several important ways.

Real-time equipment monitoring: InfluxDB ingests data from PLCs, SCADA systems, and IIoT sensors via standard industrial protocols like MQTT, OPC UA, and Modbus through its Telegraf agent. This creates a live feed of equipment health data that maintenance teams can use to spot anomalies as they develop.
Historical context for predictive models: Effective predictive maintenance depends on having deep historical data to train machine learning models. InfluxDB stores years of sensor data in a compressed columnar format, making it practical and cost-effective to retain the historical depth that ML models need to identify failure patterns.
Bridging OT and IT systems: One of the persistent challenges in MRO is that operational technology and information technology often exist in separate silos. InfluxDB integrates with both sides of this divide, connecting industrial data sources at the edge with analytics tools, cloud platforms, and AI/ML pipelines on the IT side.
Edge-to-cloud flexibility: Not every facility has the same infrastructure. Some need on-premises data processing for latency or security reasons; others want cloud-based analytics. InfluxDB supports deployment at the edge, in private clouds, or in fully-managed cloud environments, allowing organizations to match their data architecture to their operational reality.

The practical impact is tangible. Seadrill has reported saving over $1.6 million in a single year by using InfluxDB as its time series database for equipment monitoring. Siemens Energy uses InfluxDB to monitor 23,000 battery modules across more than 70 sites, analyzing billions of sensor readings to prevent downtime and ensure quality.

For operations and maintenance teams evaluating their data infrastructure, the key question is whether their current systems can handle the data volumes that condition-based and predictive maintenance demand. If the answer is no, a time series database is the foundational layer that makes advanced maintenance strategies possible.

Common MRO challenges

Even well-intentioned MRO programs run into recurring problems.

Fragmented Spending

This is the most widespread issue. When every department or site purchases MRO supplies independently, organizations lose leverage with suppliers and have no visibility into total spend.

Reactive Maintenance Culture

This culture remains entrenched in many organizations. ABB’s Value of Reliability research found that two-thirds of companies experience unplanned downtime at least once per month, and a full third have not undertaken motor or drive modernization projects in the past two years, even though upgrading obsolete equipment can generate ROI in less than two years.

Poor Data Quality

Poor data quality undermines almost every MRO improvement effort. Incomplete asset records, mislabeled parts, and patchy work-order histories make it difficult to decide what to stock, when to maintain, and where to invest. This problem compounds as organizations try to implement predictive maintenance, which depends entirely on clean, structured, time-stamped data.

Excess and Obsolete Inventory

Excess and obsolete inventory tie up capital and warehouse space. Parts ordered for equipment that has since been retired, or spares stocked based on outdated failure rates, accumulate quietly until someone audits the stockroom.

How to improve an MRO strategy

There is no single playbook for MRO improvement, but a few principles apply broadly.

Start with visibility. Before you optimize anything, you need a clear picture of what you are spending, where your inventory sits, and how your assets are performing. Consolidating data from procurement, maintenance, and inventory systems is almost always the first step.
Classify assets by criticality. Not all equipment deserves the same level of attention. Focus preventive and predictive maintenance resources on the assets whose failure would cause the greatest impact on safety, production, or cost.
Consolidate suppliers and standardize parts. Reducing the number of MRO suppliers simplifies procurement, improves negotiating leverage, and makes it easier to manage inventory. Standardizing on common parts across similar equipment reduces the total number of SKUs you need to carry.
Shift from reactive to proactive maintenance. This is a long-term cultural change, not a one-time project. Start with the highest-criticality assets, prove the value with condition monitoring and predictive analytics, and then scale. Organizations that make this transition consistently report dramatic reductions in both downtime and total maintenance cost.
Invest in the right data infrastructure. Advanced maintenance strategies are only as good as the data infrastructure behind them. This means CMMS/EAM software for work order management, time series databases for high-frequency sensor data, and integration layers that connect these systems so that insights flow from the sensor to the decision-maker without friction.
Measure what matters. Track metrics that connect MRO performance to business outcomes: planned vs. unplanned maintenance ratio, spare parts availability, mean time between failures (MTBF), overall equipment effectiveness (OEE), and maintenance cost as a percentage of asset replacement value.

Wrapping up

MRO may not be the most glamorous line item in an operating budget, but it is one of the most consequential. The organizations that treat maintenance, repair, and operations as a strategic function consistently outperform those that don’t. As sensor technology gets cheaper, predictive analytics gets smarter, and the data infrastructure to support them becomes more accessible, the gap between reactive and proactive organizations will only widen. The best time to invest in your MRO strategy was five years ago. The second-best time is now.

MRO FAQs

What does MRO stand for?

MRO most commonly stands for maintenance, repair, and operations—the activities, supplies, and services that keep equipment and facilities running. In aviation and heavy industry, MRO can also stand for maintenance, repair, and overhaul, where "overhaul" refers to the complete teardown, inspection, and rebuild of a component or system to original specifications. Both meanings describe the same core concept: sustaining operational readiness of physical assets.

What is MRO in business?

In a business context, MRO refers to all indirect spending related to keeping operations running. This includes everything from preventive maintenance schedules and spare parts to safety equipment, cleaning supplies, and facility consumables. MRO sits outside of direct production costs but has a significant impact on uptime, safety, and total operating expense.

What is the difference between MRO inventory and production inventory?

Production inventory consists of raw materials and components that become part of the finished product. MRO inventory includes spare parts, tools, consumables, and supplies used to maintain equipment and facilities; items that support production but never appear in the final product. Both require management, but they serve different purposes and are often handled by different teams with different procurement strategies.

What is MRO in manufacturing?

In manufacturing, MRO covers the indirect materials (lubricants, filters, PPE, tools, electrical components) and maintenance activities (inspections, repairs, preventive maintenance) required to keep production equipment operational. It is one of the largest categories of indirect spending in most manufacturing organizations.

What is MRO in aviation?

In aviation, MRO stands for maintenance, repair, and overhaul. It is a heavily regulated segment that includes line maintenance, airframe and engine maintenance, component repair, and full overhauls of aircraft systems. Aviation MRO is essential for airworthiness certification and passenger safety, and it is governed by regulatory bodies like the FAA and EASA.

What are MRO supplies?

MRO supplies are the materials purchased to support maintenance and operational activities. Common examples include spare parts, fasteners, lubricants, hand tools, safety gear, cleaning products, electrical components, and facility consumables like light bulbs and HVAC filters. These items are consumed during the maintenance process rather than incorporated into a finished product.

Why is MRO important?

MRO directly affects equipment uptime, workplace safety, regulatory compliance, and operating costs. Unplanned downtime alone costs U.S. manufacturers an estimated $50 billion per year. Organizations that manage MRO effectively experience fewer breakdowns, lower total maintenance costs, longer asset lifespans, and better safety records. As maintenance strategies evolve from reactive to predictive, the strategic importance of MRO continues to grow.

What is the difference between preventive and predictive maintenance?

Preventive maintenance follows a fixed schedule. For example, replacing a filter every 90 days regardless of its condition. Predictive maintenance uses real-time data from sensors to forecast when maintenance is actually needed, based on the condition and performance trends of the equipment. Predictive approaches reduce both unnecessary maintenance and unexpected failures, but they require investment in sensors, data infrastructure, and analytics tools.

What is a CMMS and how does it relate to MRO?

A CMMS (computerized maintenance management system) is software used to schedule, track, and document maintenance activities. It is one of the core tools in an MRO program, helping teams manage work orders, track asset history, plan preventive maintenance schedules, and monitor spare parts inventory. More advanced platforms (often called EAM, or enterprise asset management systems) add lifecycle planning, capital project tracking, and integration with other enterprise systems.

Telegraf Enterprise Beta is Now Available: Centralized Control for Telegraf at Scale

Scott Anderson (InfluxData) — Thu, 26 Mar 2026 07:30:00 +0000

Telegraf is incredibly good at what it does: collecting metrics, logs, and events from just about anywhere and sending them wherever you need. But once Telegraf becomes part of your production telemetry pipeline, spread across environments, teams, regions, and edge locations, the hard part isn’t installing agents; it’s operating them.

Configs drift. “Temporary” overrides linger. Rolling out changes across hundreds (or thousands) of agents becomes a careful, manual process. And when something breaks, the first question is rarely about the data—it’s about the fleet:

which configuration is running where, and is every agent healthy?

That’s the problem Telegraf Enterprise is built to solve.

Today, we’re opening the Telegraf Enterprise beta to the broader Telegraf community so you can help us validate the product where it matters most: at scale.

What is Telegraf Enterprise?

Telegraf Enterprise is a commercial offering for organizations running Telegraf at scale and needing centralized management, governance, and support. It brings together two key components:

Telegraf Controller: A control plane (UI + API) that centralizes Telegraf configuration management and fleet health visibility.
Telegraf Enterprise Support: Official support for Telegraf Controller and official Telegraf plugins, designed for teams that need dependable response times and expert guidance.

It’s built for real-world, large-scale agent deployments, where Telegraf isn’t a tool you occasionally touch, but a platform you rely on.

Meet Telegraf Controller: your Telegraf control plane

At the heart of Telegraf Enterprise is Telegraf Controller, which centralizes two things teams struggle with most at scale:

Configuration Management That Doesn’t Collapse Under Growth

Telegraf Controller helps you create and manage configurations to support consistency across environments while still allowing necessary variation. Core capabilities include:

Centralized configuration creation and editing
Templates and parameterization to reuse configs safely
Label-based organization (so fleets don’t devolve into a long list of “agent-123”)
Bulk operations for fleet-wide changes
Environment variable and parameter management
Plugin metadata visibility to simplify config authoring and maintenance

Fleet-Wide Health Visibility

Telegraf Controller gives you a single view into the overall status of your agent deployments, so you can understand:

Which agents are reporting as expected
Where health issues are clustering
What changed recently, and what might be correlated

In other words, you don’t just manage Telegraf. You operate it.

Designed to fit your telemetry stack

Telegraf Enterprise is designed to work with the way teams actually deploy Telegraf.

It does not require InfluxDB. You can use the Telegraf Controller regardless of where your telemetry data is going.
Configuration delivery follows a pull-based model, where agents fetch configuration over HTTP. This keeps change management predictable and compatible with locked-down environments.
It’s built to support hundreds to thousands of agents, with production-grade storage options and a modern UI + API architecture for automation.

Why we’re running this beta

This beta is open to any Telegraf user who wants to test-drive Telegraf Controller.

The focus of the beta is simple:

Test Telegraf Controller at scale: We want to validate how well Telegraf Controller holds up when you connect real fleets—hundreds or thousands of agents—with real operational behaviors.
Gather feedback from the community: We’re intentionally inviting community input early, while we’re still shaping the GA experience. What workflows are missing? What’s confusing? What would make this tool indispensable in your environment?

At this stage, your feedback directly influences what Telegraf Enterprise becomes.

Enterprise support that matches production expectations

Operating telemetry pipelines is a production responsibility, and when Telegraf is part of that pipeline, you need support that understands the stakes.

Telegraf Enterprise includes support designed for teams that need:

Clear expectations for response and escalation
Coverage for Telegraf Controller and official Telegraf plugins
Help diagnosing issues and reducing operational risk as fleets grow

This is especially valuable when Telegraf is deployed across multiple teams, environments, or customer sites, where operational consistency matters as much as collection capability.

Who is Telegraf Enterprise for?

Telegraf Enterprise is built for organizations that manage Telegraf fleets at a meaningful scale, including:

Platform engineering and SRE teams
DevOps organizations operating across multi-cloud / hybrid / edge
Managed service providers delivering telemetry as a service
Compliance-sensitive teams that need standardized configurations and governance

If you’re running a small number of agents and are comfortable managing configs manually, you may not need Telegraf Enterprise today. But if Telegraf is everywhere—and your team is responsible for keeping it reliable—centralized control quickly becomes less “nice to have” and more “how did we operate without this?”

Packaging: free and enterprise options

Telegraf Controller

A free tier is available for teams that want centralized configuration management and visibility with pre-defined limits.

Telegraf Enterprise

For teams operating Telegraf as critical infrastructure, Telegraf Enterprise includes the Telegraf Controller packaged with enterprise support.

The key difference: the Telegraf Enterprise is built for scale and operational reliability, with support and capabilities aligned to production fleet management.

Getting started with Telegraf Controller

Telegraf Enterprise is designed for teams operating Telegraf as a core part of production telemetry pipelines. If Telegraf is already how you collect metrics, logs, and events across your infrastructure, Telegraf Controller is the missing piece that helps you operate that collection layer like a platform—not a pile of configs.

To join the beta, click here to opt in. Please share your feedback in-app with the feedback button or our slack channel #telegraf-enterprise-beta.

Join the beta, push it hard, share your use case, and what makes your workflow easier!

Unifying Telemetry in Battery Energy Storage Systems

Allyson Boate (InfluxData) — Thu, 19 Mar 2026 08:00:00 +0000

Battery energy storage systems (BESS) play a critical role in modern energy infrastructure. Utilities rely on these systems to balance renewable generation, stabilize grid operations, and respond to changing electricity demand. As deployments scale in size and complexity, operators require continuous insight into battery health, system performance, and grid interaction. Operators rely on telemetry generated across several operational platforms. Battery management systems monitor cell behavior, power conversion systems, and regulate energy flow, while plant control platforms track facility status. Energy management software and environmental sensors provide additional context about facility conditions.

In many deployments, however, this information remains scattered across separate monitoring environments. Operators often move between multiple dashboards to understand activity across a single facility. Many BESS operators are now adopting unified telemetry platforms that consolidate operational signals and create a clearer operational view of system behavior.

The operational reality of modern BESS systems

A battery energy storage facility is not a single system but a collection of specialized subsystems that manage energy storage, power conversion, and grid interaction. Each subsystem monitors a different aspect of facility performance and generates operational signals that help operators understand how the system behaves.

Several platforms produce these signals. Battery Management Systems (BMS) track cell-level conditions such as voltage, temperature, and state of charge to protect battery health. Power Conversion Systems (PCS), typically implemented through inverters, regulate how electricity flows between the battery and the grid.

Plant-level monitoring runs through SCADA platforms, which provide alarms, system status, and operational controls. Energy Management Systems (EMS) determine when energy should be stored or dispatched based on grid signals and market conditions, while environmental sensors monitor external factors such as ambient temperature.

Together, these systems create a continuous operational record of facility performance, but the resulting information does not always exist in a shared environment.

The fragmented reality of BESS telemetry

In most battery energy storage deployments, operational data originates from multiple independent platforms, as described above. This fragmentation reflects the modular design and deployment of energy storage facilities. Battery systems, power conversion equipment, and plant control platforms are frequently delivered by different vendors, each with its own software, data models, and monitoring tools.

Because these platforms monitor individual components rather than the entire facility, data is rarely consolidated automatically. Operators often rely on multiple dashboards to understand activity across a single storage site. Correlating events between subsystems may require switching between tools and manually comparing timestamps or operational signals.

The result? Operators have access to large volumes of operational information but lack a unified view of the facility as a whole. When events occur across multiple subsystems, understanding how those signals relate to one another requires time and effort.

Operational cost of data silos

Even small issues can require significant labor to diagnose. The data silos created by ala carte technologies prevent engineers from seeing how signals across the storage system relate.For example, a thermal anomaly—an unexpected rise in battery temperature—may require operators to review battery readings, compare inverter load behavior, and examine environmental conditions. Without a unified view of these signals, determining the cause can take time.

These delays affect both system reliability and financial performance. If operators cannot quickly determine why system capacity dropped or alarms triggered, dispatch readiness may be affected during critical market windows. Over time, slower investigations and delayed anomaly detection can lead to reduced system availability, higher operational overhead, and missed revenue opportunities.

What unified telemetry actually means

Unified telemetry consolidates operational signals from across the storage system into a shared data environment. Instead of storing data separately within subsystem platforms, telemetry from across the facility enters a common dataset.

In this environment, operational signals are stored as time-series data, or measurements organized by timestamp, allowing signals from different subsystems to be synchronized and analyzed together.

This shared dataset allows engineers to correlate signals that were previously isolated. Battery temperature trends can be examined alongside inverter load behavior, dispatch signals, and environmental conditions to better understand system performance. Instead of switching between monitoring platforms, operators can observe how signals across subsystems evolve together within a unified operational timeline.

How unified telemetry works

In many deployments, telemetry aggregation begins at the edge of the facility. Edge collectors connect to operational systems such as the BMS, PCS, SCADA platform, EMS and environmental sensors using industrial protocols such as Modbus, OPC-UA, or CANbus. These collectors ingest operational signals and convert them into structured telemetry streams.

From there, the data flows through streaming pipelines into centralized platforms. These pipelines handle ingestion, buffering, and transport of high-frequency signals so information from across the facility can be processed as a continuous operational stream.

Time series databases store and index this telemetry by timestamp, allowing engineers to query system behavior over time. Organizing operational signals this way enables teams to correlate events across subsystems, analyze performance trends, and investigate anomalies.

Because signals from different systems exist in the same time-aligned dataset, engineers can examine battery performance, inverter activity, dispatch signals, and environmental conditions together. This enables faster incident investigation and supports advanced analysis such as anomaly detection and predictive maintenance.

Operational impact

Unified telemetry changes how energy storage facilities are operated and how organizations manage risk, reliability, and revenue. When signals from battery systems, power electronics, and plant controls are analyzed together, operators gain a comprehensive view of facility behavior rather than having to reconstruct events across multiple monitoring platforms.

This visibility allows teams to detect anomalies earlier and respond to operational issues before they escalate. Faster diagnosis reduces downtime and helps maintain system availability during critical dispatch windows. In energy markets, maintaining dispatch readiness helps protect revenue during high-value trading periods.

ju:niz Energy Deployment

ju:niz Energy operates large-scale battery storage systems that provide grid services and trading flexibility in energy markets. Their systems collect thousands of data points per second on battery health, temperature, climate conditions, and system performance.

To manage this telemetry, ju:niz built a centralized monitoring architecture using Telegraf, Modbus, MQTT, Grafana, Docker, AWS, and InfluxDB. Operational signals from battery systems stream into a centralized time series platform, giving engineers a unified view of system behavior and eliminating the need for legacy Python monitoring scripts.

This architecture enables the ju:niz team to analyze battery telemetry in real-time, improve alerting accuracy, and support predictive maintenance strategies across their storage infrastructure.To see how ju:niz implemented unified telemetry for its operations, read the full case study or watch the webinar.

The bottom line

Battery energy storage systems generate telemetry across multiple operational platforms, but when that data remains fragmented, operators struggle to understand how the system behaves as a whole. Unified telemetry solves this by bringing operational signals into a shared, time-aligned dataset. As BESS deployments scale, this capability will become foundational for operating energy storage systems reliably, efficiently, and profitably.

Ready to build a unified telemetry architecture? Get started with a free download of InfluxDB 3 Core OSS or a trial of InfluxDB 3 Enterprise.

A New Scale Tier for Time Series on Amazon Timestream for InfluxDB

Pat Walsh (InfluxData) — Mon, 16 Mar 2026 08:00:00 +0000

When we first announced the availability of InfluxDB 3 Core and Enterprise on Amazon Timestream for InfluxDB last year, we set a new standard for managed time series on AWS. We gave developers a simple way to harness high performance at scale while removing the burden of infrastructure management.

But as our customers have taught us, “at scale” is a moving target. Across Industrial IoT, physical AI, and real-time observability, data is growing in both volume and resolution. When you move from minute-by-minute polling to sub-millisecond, high-fidelity telemetry, the pressure on the underlying database compounds. To stay ahead of that curve, developers need a platform that scales as fast as their workloads.

Today, we’re delivering that by expanding InfluxDB 3 on Amazon Timestream for InfluxDB to support expanding clusters up to 15 nodes. We’re also introducing a seamless migration path from InfluxDB 3 Core to InfluxDB 3 Enterprise, allowing teams to unlock this massive performance tier without friction, risk of a manual architectural overhaul, or any data loss.

Scaling for the mission-critical

At InfluxData, we’re seeing time series expand from infrastructure monitoring to the foundation for autonomous systems. In high-stakes environments like power grid management or autonomous vehicle navigation, increased latency is a significant operational risk rather than just a performance metric.

Previously, AWS Timestream’s support of InfluxDB 3 was focused on smaller, highly efficient configurations. By expanding to 15 nodes, we are providing major upgrades across three important areas:

Query concurrency: More nodes mean more hands on deck to process complex, concurrent queries. Large teams can now run heavy analytical workloads without impacting real-time dashboards or critical alerts.
Massive throughput: With a larger cluster, you can ingest millions of data points per second across hundreds of millions of unique series, maintaining real-time query performance.
Workload isolation and optimization: These expanded clusters enable true functional isolation between ingestion, queries, and compaction. This allows granular performance tuning optimized for your most demanding workloads.

Architected for enterprise demand

This new 15-node option is available for InfluxDB 3 Enterprise and is designed for organizations that require high availability, enhanced security, and the power to maintain high ingestion and real-time query performance across high-resolution, high-velocity datasets. InfluxDB 3 Core will continue to operate in single-node deployments.

By leveraging AWS infrastructure, you can spin up these expanded clusters in minutes directly from the AWS Console. With our new seamless migration capabilities, you can transition your existing Core workloads to Enterprise clusters with a single click. This ensures that as your data grows (from a few local sensors to a global fleet of devices), your database never becomes the bottleneck, and your team never has to worry about the downtime typically associated with a migration. These larger clusters are available today in all AWS regions where Amazon Timestream for InfluxDB is available, ensuring you can deploy and optimize mission-critical time series infrastructure wherever your data lives.

The foundation for physical AI

Our partnership with AWS is about meeting developers where they build. By integrating with services like AWS Lambda, SageMaker, and Kinesis, we’ve simplified the path from high-volume streams into Physical AI. This is the frontier where intelligence moves from the digital realm into the physical world.

Time series is the heartbeat of this transition, fueling a two-part lifecycle:

Training: Using massive volumes of historical data to establish baselines and “normal” patterns.
Inference: Streaming real-time data against those models to trigger automated, deterministic actions.

What makes our partnership with AWS unique is that we support both sides of this loop. With up to 15 nodes at your disposal, InfluxDB 3 has the headroom to act as a distributed inference engine, running predictive maintenance and anomaly detection against your data. This eliminates the latency tax of moving massive datasets between layers, ensuring that whether you are managing a robotic fleet or a smart grid, your autonomous systems can perceive and react with real-time precision.

What’s next?

The future of time series is about speed, precision, and scale. With today’s announcement, we’re handing you the keys to all three. By removing the barriers between single-node efficiency and enterprise-grade performance, we’re making it easier than ever to evolve your architecture as fast as your data grows.

We’re excited to see what the community builds with this new level of power. If you’re ready to scale your real-time workloads, head over to the AWS Console and start building.

What is Industry 4.0? Everything You Need to Know in 2026

Company (InfluxData) — Fri, 13 Mar 2026 08:00:00 +0000

Industry 4.0 is the term used to describe the fourth industrial revolution, a name given to the integration of physical and digital systems, which includes the internet of things (IoT) and artificial intelligence that are transforming a huge number of industries.

At a high level, its goal is to create an efficient, automated process for creating products or services that can be adapted quickly and efficiently to changing customer needs.

Industry 4.0 also includes concepts such as cloud computing, big data analytics, and machine learning to enable smarter production processes.

By using sensors and automation technology, manufacturers can collect real-time data on their machines and operations, which can be analyzed to make more informed decisions about how best to manage resources, optimize production lines, and reduce costs.

Industry 4.0 is leading manufacturers away from the traditional linear, push-based approach to production toward a new data-driven, customer-centric model. This “smart” manufacturing can help businesses remain competitive and stay ahead of the curve in terms of production capabilities, while also contributing to a more sustainable future.

The path to Industry 4.0

Let’s take a look at how we arrived at Industry 4.0 by looking to the past. This additional context will help give you a better understanding of why Industry 4.0 is important and why so many people think it is valuable to adopt these technologies.

First Industrial Revolution

The First Industrial Revolution, which took place in the late 18th and early 19th centuries, was characterized by the mechanization of production, the use of steam power, and the development of the factory system.

This revolution led to significant changes in manufacturing, transportation, and communication, and had a major impact on society and the economy.

Second Industrial Revolution

The Second Industrial Revolution took place in the late 19th and early 20th centuries. It was characterized by mass production of goods, the use of electricity, and the development of the assembly line.

Third Industrial Revolution

The Third Industrial Revolution, also known as the Digital Revolution, took place in the late 20th and early 21st centuries and was characterized by the adoption of computers and automation in manufacturing and other industries.

Fourth Industrial Revolution

Industry 4.0, also known as the Fourth Industrial Revolution, is the current trend of automation and data exchange in manufacturing technologies, including developments in artificial intelligence, the internet of things (IoT), and cyber-physical systems.

It’s seen as the fourth major revolution in manufacturing, following the mechanization of production in the First Industrial Revolution, the mass production of the Second Industrial Revolution, and the introduction of computers and automation in the Third Industrial Revolution.

Industry 4.0 key concepts and principles

Interoperability

Interoperability is a fundamental concept in Industry 4.0, emphasizing seamless communication and data exchange among systems, devices, and software platforms within an industrial environment.

As Industry 4.0 relies heavily on integrating diverse technologies such as IoT, AI, and cloud computing, ensuring these components work effectively together is crucial to realizing the full potential of a connected, intelligent manufacturing ecosystem.

Interoperability enables businesses to break down silos, streamline processes, and make better-informed decisions, ultimately leading to increased efficiency, productivity, and competitiveness.

To achieve interoperability, manufacturers must adopt standardized communication protocols, open architectures, and flexible data formats to facilitate a smooth flow of information across the entire production chain.

Virtualization

Virtualization is the creation of virtual representations of physical assets, processes, and systems within the industrial environment.

By using advanced technologies such as digital twins, simulation software, and augmented reality, virtualization enables manufacturers to test, analyze, and optimize their operations without impacting the actual production process.

Virtualization not only allows more efficient planning and decision making but also helps businesses identify potential bottlenecks or issues before they occur, resulting in reduced downtime, lower costs, and enhanced product quality.

At the same time, it promotes remote monitoring and control of industrial processes, allowing experts to collaborate and troubleshoot issues from any location, which improves overall operational efficiency.

Cyber-Physical Systems

Cyber-physical systems (CPS) are a core part of Industry 4.0, representing the seamless integration of computational and physical components. These systems enable real-time communication and data exchange between machines, humans, and digital networks, resulting in smarter, more efficient, and autonomous industrial processes.

Decentralization

Decentralization involves the shift towards distributed decision-making and autonomous control within industrial systems.

In the context of manufacturing, decentralization empowers machines, devices, and production units to make decisions and perform tasks independently, without centralized supervision or control.

This approach increases the agility and resilience of manufacturing operations and enables businesses to scale more effectively, as new components or devices can be seamlessly integrated into the existing network.

Modularity

Modularity, the ability to adjust production lines, processes, and equipment with minimal effort and downtime, is a key concept in Industry 4.0.

It emphasizes the importance of designing flexible, scalable, and adaptable systems that can be easily reconfigured or upgraded to meet changing market demands and technological advancements.

By embracing modularity, manufacturers can rapidly adapt to fluctuations in product demand, introduce new products, or incorporate emerging technologies, ensuring their operations remain agile and competitive.

Modularity also enables greater customization, as production lines can be adjusted to accommodate unique customer requirements or preferences.

What technologies are driving Industry 4.0?

Internet of Things

IoT is an important part of Industry 4.0, enabling businesses to optimize processes and become more efficient. With this technology, companies can deploy intelligent machines to automate processes and workflows, leading to higher accuracy and productivity.

IoT technology also makes it possible for machines and databases to communicate, allowing businesses to access real-time data. This improved data collection has enabled insights about productivity and efficiency, streamlining many processes in Industry 4.0.

Cloud Computing

Cloud computing enables new ways for organizations to develop agile digital operations. By using cloud computing, companies can reduce the time needed to deploy or upgrade applications and further benefit from scalability.

With cloud computing, manufacturers now have access to analytics data they did not previously have, enabling them to make informed, real-time decisions.

Edge Computing

Edge computing is the process of collecting and analyzing data at the edge of a network, closer to where it is generated. It’s at the opposite end of the spectrum from cloud computing, but it’s just as important for Industry 4.0 workloads.

This makes it ideal for applications that require real-time analytics, such as autonomous robotic systems and self-driving cars.

Edge computing also helps reduce network traffic by minimizing the need to send large amounts of data back and forth between devices and centralized data centers.

5G Networking

5G networks allow for faster communication and data transfer speeds, a huge factor in making Industry 4.0 viable. This ultimately makes the technology more accessible to businesses of all sizes and enables them to deploy IoT solutions at scale.

5G can enable companies to increase operational efficiency by supporting real-time decision-making and remote monitoring capabilities.

AI and Machine Learning

AI and machine learning are another key piece of making Industry 4.0 possible. Using AI, companies are able to automate processes, improve decision-making, and better analyze data.

Many industries are already using AI to increase efficiency, accelerate innovation, and reduce costs. In manufacturing, for example, AI can be used to optimize production lines, predict maintenance needs, and schedule resources more efficiently.

Cybersecurity

Collecting and analyzing more data is great, but it also opens up numerous potential vulnerabilities for businesses. No company wants to be in the news for leaking internal or customer data, or for not being able to function because critical infrastructure has been hacked.

Industry 4.0 requires sophisticated cybersecurity solutions that protect data at rest and in transit, detect malicious activity before it becomes a problem, and alert users when something is amiss. This can be accomplished through various measures such as encryption, intrusion detection systems, two-factor authentication (2FA), and network segmentation.

In addition to implementing security solutions, organizations should also develop a comprehensive cybersecurity strategy that covers personnel training and processes for responding to emergency situations. This way, businesses can be more prepared for any potential attacks or data breaches.

Digital Twins

Digital twins enable engineers to create virtual models of systems and processes that can be used to measure performance, anticipate variation, and even detect defects or dangers before they become issues in the physical world.

As a result of this technology’s high accuracy, digital twin simulations can substantially reduce design costs, improve operational efficiency and sustainability, enhance product quality, and promote workplace safety.

Furthermore, companies are leveraging the combination of digital twins’ advanced analytics capabilities and connected devices to optimize factory operations through remote commissioning, proactive maintenance, and streamlined troubleshooting.

Real-Time Data Analytics

Real-time analytics is an essential part of Industry 4.0, enabling businesses to monitor, analyze, and respond to operational and process changes with unprecedented speed and accuracy.

By utilizing IoT devices, sensors, and advanced analytics models, manufacturers can collect and process data in real time, allowing them to make data-driven decisions and adjustments on the fly.

3D Printing and Additive Manufacturing

3D printing and additive manufacturing are quickly becoming essential tools for businesses to maximize efficiency, reduce costs, and create complicated designs with ease.

For example, factories can print replacement parts on-site without having to call a supplier and wait for them to arrive. This means faster repairs and less downtime overall.

Additive manufacturing also allows companies to manufacture complex designs that were previously impossible with traditional manufacturing methods.

Robotics

In the context of Industry 4.0, robotics goes beyond traditional automation, incorporating advanced capabilities such as AI, machine learning, and sensor integration to create intelligent, adaptive, and versatile machines capable of performing complex tasks with precision and consistency.

This also includes collaborative robots, or “cobots,” which are designed to work alongside human operators, enhancing their capabilities and ensuring a safer, more ergonomic work environment. By using robotics, manufacturers can automate repetitive tasks, reduce human error, and reduce labor costs, while also enabling greater flexibility and customization in production.

Benefits of Industry 4.0

1. Improved productivity

One of the primary benefits of Industry 4.0 is improved productivity. Key 4.0 technologies, such as data analytics and machine learning, can be used to identify inefficiencies and optimize production processes.

Similarly, robotics and 3D printing can automate tasks, reducing the need for human labor and increasing manufacturing output.

2. Increased efficiency

By enabling smarter use of resources and more efficient processes, Industry 4.0 contributes significantly to reducing energy consumption, waste generation, and greenhouse gas emissions.

When companies adopt Industry 4.0 technologies, they can actively contribute to global sustainability goals while simultaneously improving their bottom line.

Predictive maintenance is a prime example. This proactive approach allows companies to monitor equipment performance in real-time, identify potential issues before they escalate, and schedule maintenance activities based on actual equipment conditions rather than fixed intervals.

Predictive maintenance minimizes unexpected downtime and costly repairs, extends equipment lifespan, reduces the need for frequent replacements, and reduces associated environmental impact. As an added bonus, equipment that is properly maintained also tends to run more efficiently in terms of power consumption and greenhouse gas emissions.

3. Improved quality

By identifying errors in collected sensor data, Industry 4.0 can also help improve product quality. Additionally, 3D printing can create prototypes that can be tested for quality before mass production begins.

4. Reduced costs

The implementation of Industry 4.0 technologies helps minimize expenses because these technologies can help improve productivity and efficiency, leading to reduced labor costs and waste.

5. Increased flexibility

Industry 4.0 helps to increase flexibility within manufacturing operations. Technologies such as 3D printing and robotics can be used to create customized products quickly and with minimal human labor.

The use of data analytics also helps companies respond to changes in customer demand, scaling production up or down when needed.

6. Enhanced safety

Thanks to advances such as robotics and machine learning, dangerous tasks can now be automated. This reduces the risk of worker injury and helps create a safer working environment.

7. More resilient supply chains

Adopting many Industry 4.0 technologies can help businesses strengthen their supply chains. By leveraging data analytics, businesses can monitor the production process in real time and detect small issues before they escalate into larger problems.

Plus, 3D printing and additive manufacturing can also be used to quickly produce replacement parts or components for machinery with little to no downtime. This helps companies maintain operations without disruption due to supply chain problems.

8. Improved customer experience

Industry 4.0 can help businesses improve their customer experience by providing insights into customer behaviors and preferences. Through data analysis, companies can identify areas where they need to focus their efforts in order to provide the best possible service or product.

Data can also help during the manufacturing process to help identify potential defects early, so customers don’t receive a faulty product.

Industry 4.0 challenges and risks

1. Implementation costs

Implementing Industry 4.0 technologies and practices can be expensive, particularly for smaller businesses. If a business doesn’t have the necessary financial resources to invest in these technologies, it may not see a return on the investment.

2. Cybersecurity risks

The integration of advanced technologies and the reliance on connected systems increase the risk of cybersecurity threats. Without robust cybersecurity measures in place, a business may be vulnerable to attacks, which can have serious consequences.

3. Culture challenges

Some businesses may be hesitant to adopt new technologies and practices due to concerns about costs and disruptions to their existing operations. If a business isn’t willing to adapt to new technologies and processes, it may struggle to compete with competitors that are more forward-thinking.

This can also apply to employees who aren’t familiar with new technologies and may be resistant to change, making it important to ensure that employees at all levels of the company understand how and why changes are being made.

Common Industry 4.0 use cases

1. Smart manufacturing

Smart manufacturing and smart factories are common Industry 4.0 use cases where adopting new technologies can improve productivity, make products more reliable, and keep workers safer.

Beyond the direct benefits to the company, smart manufacturing can benefit the environment by reducing waste and making production more efficient.

2. Agriculture

The advantages of incorporating Industry 4.0 in agriculture are substantial.

Precision farming techniques, powered by IoT sensors and data analytics, facilitate the targeted application of fertilizers, pesticides, and irrigation, reducing waste and minimizing environmental impact.

Robotics and autonomous machinery can also perform repetitive tasks, such as planting, harvesting, and monitoring, improving efficiency and freeing up valuable human resources.

Advanced data analysis also enables predictive modeling and forecasting, helping farmers make informed decisions on crop selection, planting schedules, and resource allocation.

3. Healthcare

By using IoT devices to collect health data, patients are able to get more personalized and effective healthcare. This can include everything from detecting emergency situations, such as a heart attack, to enabling the detection and mitigation of diseases before they become severe.

Robotics is also increasingly used during surgery to reduce human error and improve outcomes.

4. Supply chain management

Adopting Industry 4.0 technologies can enhance supply chain management by enabling better visibility, efficiency, and resilience.

Connecting components such as suppliers, manufacturers, distributors, and retailers, enables smoother information exchange, ensuring that all stakeholders have access to accurate and up-to-date data.

Predictive analytics and machine learning can help forecast demand patterns, optimize inventory levels, and identify potential disruptions, allowing supply chain managers to address issues and minimize risks.

Industry 4.0 tools

In this section, we’ll examine some tools useful for a variety of tasks involved in adopting industry 4.0 technology.

1. Data storage

Storing Industry 4.0 data at scale requires scalable, efficient solutions that can handle the high volume of data generated by interconnected devices and systems. Here are a few different options for storing your data:

2. Time series databases

Time series databases (TSDBs) are specifically designed to store time-stamped data from sensors and IoT devices. They offer high write and query performance, making them ideal for handling the high-frequency data typical of Industry 4.0 use cases. An example of a TSDB is InfluxDB.

3. Data historians

Data historians are specialized databases for storing and retrieving historical process data from industrial systems. They are optimized for handling time series data and offer capabilities like data compression, aggregation, and real-time querying. An example of a data historian is OSI PI.

4. Columnar databases

Columnar databases store data in columns rather than rows, which is well-suited for analytics and processing large datasets and is often used as a data warehouse. Columnar databases offer high query performance and data compression, making them suitable for storing and analyzing the vast amounts of structured data generated by Industry 4.0 systems.

5. Communication protocols

Several communication protocols are well-suited for Industry 4.0 systems, providing efficient and reliable data transfer between interconnected devices, machines, and software platforms. Here are some good options for communication protocols in Industry 4.0:

6. MQTT

MQTT is a lightweight, publish-subscribe messaging protocol designed for low-bandwidth, high-latency, and unreliable networks. Its low overhead and minimal resource requirements make it ideal for IoT devices and Industry 4.0 applications.

MQTT is widely used to connect sensors, actuators, and other devices to cloud platforms, enabling efficient data exchange and remote monitoring.

7. OPC Unified Architecture (OPC UA)

OPC UA is a platform-independent, service-oriented architecture developed specifically for industrial automation and communication. It provides secure and reliable data exchange between devices, machines, and software applications, regardless of the underlying platform or programming language.

OPC UA supports a wide range of data types and features with built-in security mechanisms, making it a popular choice for Industry 4.0 systems.

8. Advanced Message Queuing Protocol (AMQP)

AMQP is an open standard, application-layer protocol for message-oriented middleware. It supports flexible messaging patterns and offers reliable, secure communication between devices and applications. AMQP is well-suited to scenarios that require complex routing and guaranteed message delivery, making it a good fit for many Industry 4.0 applications.

Data Collection and Integration

One of the big challenges for Industry 4.0 is collecting data from a variety of devices that may communicate over different protocols, then sending it to various tools for storage and analysis. Let’s take a look at some options that make collecting and integrating data easier:

1. Node-RED

Node-RED is an open-source, flow-based programming tool for wiring together devices, APIs, and online services. It provides a browser-based visual interface for designing and deploying data flows, making it easy to connect and integrate various data sources, such as IoT devices, industrial sensors, and web services.

With a large library of prebuilt nodes and support for custom nodes, Node-RED allows users to build complex data pipelines and perform data transformations with minimal coding effort.

2. Telegraf

Telegraf is an open source, plugin-driven server agent for collecting and reporting metrics from different data sources. Telegraf supports a wide range of input, output, and processing plugins, allowing it to gather and transmit data from various devices, systems, and APIs to different storage platforms.

Its flexibility and extensibility make it suitable for Industry 4.0 applications, where diverse data sources are common.

3. Apache NiFi

Apache NiFi is an open source, web-based data integration tool for designing, deploying, and managing data flows. It offers a visual interface for designing data pipelines and supports a wide range of data sources, processors, and sinks.

NiFi is particularly well-suited to use cases that require complex data routing, transformation, and enrichment. With built-in security features and support for data provenance, NiFi ensures data integrity and traceability in Industry 4.0 environments.

Industry 4.0 best practices

Moving towards Industry 4.0 is a major endeavor for existing businesses and involves all areas of a business to work properly. In this section, let’s explore some best practices that can help you avoid major pitfalls that could hurt your business.

1. Have a clear strategy and goals

Above all else, you need a clear understanding of how adopting these new technologies will help achieve your business goals. If you can’t actually find concrete ways that this will help your business, don’t blindly invest resources in them. Some potential things to identify:

Specific technologies that will be used
Which processes could be automated
Metrics to measure success
Cybersecurity focus

The integration of advanced technologies and the reliance on connected systems increase the risk of cybersecurity threats. Implement robust cybersecurity measures to protect against these threats from day one, so you don’t regret it later on.

2. Collaboration

Industry 4.0 technologies often involve integrating systems and processes across different organizations. It’s important to collaborate with suppliers and partners to ensure that these systems and processes are integrated effectively.

3. Track results and iterate

Establish metrics before starting so you can measure progress against expected results. Based on progress, you need to be willing and able to change your strategy if necessary.

FAQs

What are the origins of Industry 4.0?

Industry 4.0 as a concept dates back to 2006, when the German government laid out a plan to maintain its manufacturing dominance in a paper that looked into the future of manufacturing and how companies would be impacted and need to adapt to emerging technologies. The concept was further refined in 2010 when the German Cabinet laid out their High-Tech Strategy 2020 plan, which defined five priorities that would be used to direct billions of dollars in government investment.

How are digital transformation and Industry 4.0 related?

Digital transformation and Industry 4.0 are often used interchangeably, but it's crucial to understand their unique characteristics and how they relate to each other. While both concepts involve adopting advanced technologies to improve business operations, Industry 4.0 specifically focuses on the manufacturing sector, whereas digital transformation encompasses a broader range of industries and applications. Digital transformation is the process of integrating digital technologies across a business's customer service, marketing, supply chain management, and internal operations. The goal of digital transformation is to optimize processes, enhance efficiency, and create new business models that drive growth and competitiveness. This transformation is achieved through the implementation of technologies such as cloud computing, data analytics, artificial intelligence, and IoT. Industry 4.0, on the other hand, is a subset of digital transformation that targets the manufacturing industry. It is often referred to as the Fourth Industrial Revolution, representing a new era of intelligent, connected, and autonomous manufacturing systems. Industry 4.0 leverages technologies like IoT, advanced analytics, robotics, and additive manufacturing to optimize production processes, improve product quality, and increase overall efficiency. Despite their differences, digital transformation and Industry 4.0 are closely related, as both aim to drive innovation and create value through the adoption of advanced technologies. In fact, Industry 4.0 can be considered a specific application of digital transformation within the manufacturing sector. As companies embark on their digital transformation journeys, embracing Industry 4.0 principles can provide a solid foundation for growth and success in manufacturing.

What is IT/OT convergence?

Businesses have traditionally been siloed between information technology (IT) and operational technology (OT). But in recent years, these worlds have started to merge in a process commonly referred to as IT/OT convergence. Better collaboration between IT and OT can add tremendous value to any business by providing greater visibility across the organization, improved data analysis capabilities, fewer manual processes, and a faster response to customer needs. By leveraging both sets of technologies, businesses can gain unprecedented control over their operations. IT/OT convergence involves integrating hardware, software, and networks traditionally used in OT with those used in IT. This integration synchronizes the two disconnected systems, allowing them to exchange data and information. For example, an IT system can enable operators to access real-time operational data from OT systems, such as sensors and actuators.

What is Industry 5.0?

Industry 5.0 is a term used to describe the next phase of the Fourth Industrial Revolution, characterized by the integration of advanced technologies such as AI, IoT, and quantum computing into manufacturing and other industries. There isn't a universally accepted definition of Industry 5.0, and the concept is still evolving. However, it's generally seen as a continuation of the trend towards increased automation and data exchange that began with Industry 4.0, with a focus on even more advanced technologies and their integration across sectors. One key difference between Industry 4.0 and Industry 5.0 is the focus on sustainability and social responsibility. Industry 5.0 is expected to involve the development of technologies that are more environmentally friendly and that promote social equity. This could include using renewable energy sources and developing technologies to reduce waste and pollution. Overall, the main difference between Industry 4.0 and Industry 5.0 is the level of technological advancement. Industry 5.0 involves the integration of even more advanced technologies, such as quantum computing, which have the potential to significantly impact and transform various industries.

When Your Plant Talks Back: Conversational AI with InfluxDB 3

Suyash Joshi (InfluxData) — Tue, 10 Mar 2026 08:00:00 +0000

No one wants to stare at a plant and guess if it needs water. It’s much easier if the plant can say, “I’m thirsty.” A few years ago, we built Plant Buddy using InfluxDB Cloud 2.0. The linked article is still a great guide for cloud-first IoT prototyping as it shows how quickly you can connect devices, store time series data, and build dashboards in the cloud with the previous version of InfluxDB.

But this time, the goal was different. Instead of sending soil moisture data to the cloud, the entire system runs locally using the latest InfluxDB 3 Core, similar to a modern industrial setup powered by LLM for a natural conversational interaction.

The architecture: the “factory” at home

In real factories, raw PLC data is captured at the edge, often using MQTT and a local database. That same architecture now powers PlantBuddy v3 with the following setup.

Edge Device (ESP32 / Arduino): Works like a small PLC. It reads soil moisture and publishes the plant’s state to the network without knowing anything about the database.
Soil Moisture Sensor (Analog): Outputs an analog signal based on soil moisture. The microcontroller converts it to digital using its built-in ADC.
Message Bus (Mosquitto MQTT): Handles publish/subscribe communication. The Arduino publishes data to the broker (running locally), and Telegraf subscribes to forward data to the database.
Database (InfluxDB 3 Core): Runs locally in Docker as a high-performance time series database storing all sensor readings.
User Interface (Claude + MCP): Enables natural language queries. Instead of writing SQL, questions about plant health can be asked conversationally.

1. Collecting & Sending Data from the Edge

To make this scalable, I treat the sensor data like an industrial payload. It’s not just a number; it’s a structured JSON object containing the ID, raw metrics, and a pre-calculated status flag.

The Arduino Payload

{ 
"id": "pothos_01",    // Device identifier (like a PLC tag) 
"raw": 715,  		// Raw ADC value (0-1023) 
"pct": 19,  		// Calculated moisture percentage 
"stat": "DRY_ALERT"   // Pre-computed status 
}

Why compute status at the edge? In factories, PLCs make local decisions (e.g., stop motor, trigger alarm). Here, the Arduino determines “DRY_ALERT” so the database can trigger alerts without recalculating thresholds.

2. The Ingest Pipeline

Below are two approaches to send plant data to InfluxDB. In this project, I went with MQTT and Telegraf, which are more standard for an industrial setup.

Telegraf acts as the gateway, subscribing to the MQTT broker and translating the JSON into InfluxDB Line Protocol. This configuration is identical to what you’d see in a manufacturing plant monitoring vibration sensors.

# telegraf.conf - Complete Working Example
[agent]
  interval = "10s"
  flush_interval = "10s"

[[inputs.mqtt_consumer]]
  servers = ["tcp://127.0.0.1:1883"]
  topics = ["home/livingroom/plant/moisture"]
  data_format = "json"

  # Tags become indexed dimensions (fast filtering)
  tag_keys = ["id", "stat"]

  # Fields become measured values
  json_string_fields = ["raw", "pct"]

[[outputs.influxdb_v2]]
  urls = ["http://127.0.0.1:8181"]
  token = "$INFLUX_TOKEN"
  organization = "my-org"
  bucket = "plant_data"

Note: If Telegraf runs in Docker, use host.docker.internal:8181 to reach the database.

3. Time Series Database: InfluxDB 3 (Docker Container)

InfluxDB 3 Core runs locally in Docker as the time series database. It stores soil moisture readings and enables real-time analytics, all without depending on external cloud connectivity.

# Create persistent storage 
mkdir -p ~/influxdb3-data

# Run InfluxDB 3 Core with proper configuration
docker run --rm -p 8181:8181 \
  -v $PWD/data:/var/lib/influxdb3/data \
  -v $PWD/plugins:/var/lib/influxdb3/plugins \
  influxdb:3-core influxdb3 serve \
    --node-id=my-node-0 \
    --object-store=file \
    --data-dir=/var/lib/influxdb3/data \
    --plugin-dir=/var/lib/influxdb3/plugins

4. The “AI” Interface: InfluxDB MCP & Claude

Instead of writing SQL queries or building dashboards, the system connects an LLM to InfluxDB through the Model Context Protocol (MCP). I’ve written another blog post on how to connect InfluxDB 3 to MCP, which you can find here.

Now the question isn’t: “What’s the SQL query for average soil moisture over the last 24 hours?”

It becomes: “Has the plant been dry today?”

The LLM generates the correct SQL under the hood. If needed, the generated query can be inspected. This makes time series analytics accessible through conversation.

claude_desktop_config.json

{
  "mcpServers": {
    "influxdb": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "--interactive",
        "--add-host=host.docker.internal:host-gateway",
        "--env",
        "INFLUX_DB_PRODUCT_TYPE",
        "--env",
        "INFLUX_DB_INSTANCE_URL",
        "--env",
        "INFLUX_DB_TOKEN",
        "influxdata/influxdb3-mcp-server"
      ],
      "env": {
        "INFLUX_DB_PRODUCT_TYPE": "core",
        "INFLUX_DB_INSTANCE_URL": "http://host.docker.internal:8181",
        "INFLUX_DB_TOKEN": "YOUR_RESOURCE_TOKEN"
      }
    }
  }
}

The Result:

What’s next

In the next post, we will upgrade this Plant Buddy project to do more than passively monitor. New features will include:

A water pump, motor, and small display.
Automatic watering when the plant enters DRY_ALERT.
An extended system with light and temperature sensors to determine how placement of the potted plant affects its health, especially during trips when no one is home.

Try to build one yourself with InfluxDB 3! We would love to hear your questions/comments in our community forum, Slack, or Discord.

From Reactive to Predictive: Preserving BESS Uptime at Scale

Allyson Boate (InfluxData) — Thu, 05 Mar 2026 08:00:00 +0000

Battery Energy Storage Systems (BESS) operate as revenue-generating grid assets that capture surplus electricity, deploy power during demand spikes, and support frequency control. By shifting energy across time, they stabilize grid conditions, enable renewable integration, and execute market dispatch commitments. When systems respond as designed, stored capacity becomes a flexible, monetizable supply.

But BESS performance depends on precision and availability. When deviations in temperature, voltage, or current go undetected, instability can propagate across battery modules and supporting systems. Dispatch commitments fail, contractual penalties follow, and safety exposure increases.

In large-scale deployments, uptime becomes a financial and operational control variable rather than a maintenance metric. Preserving availability requires more than reacting to alarms after limits are breached. As fleets expand and system complexity grows, reactive monitoring reaches its ceiling.

What is a BESS?

A Battery Energy Storage System (BESS) is a grid-connected battery infrastructure that stores electricity when supply exceeds demand and deploys it when demand rises. By shifting energy across time, these systems help balance generation and consumption while supporting market commitments and frequency control. Their value lies not only in storing energy, but in responding precisely when grid conditions change.

Electrical supply and demand must remain balanced at all times. When surplus power enters the grid, a BESS absorbs that energy and holds it until demand increases, at which point stored electricity is released back into the network. This coordinated charge-and-discharge cycle enables controlled energy movement that stabilizes supply, supports renewable energy sources, and maintains consistent grid performance.

Storage systems adjust output within seconds to correct short-term imbalances. Rapid response smooths fluctuations from wind and solar generation and helps maintain grid stability. As more renewable energy comes online and demand patterns shift, reliance on storage systems increases. In this environment, availability and response speed directly influence reliability and financial performance.

Availability as an Operational Variable

The value of a BESS depends on its availability. When a system goes offline, dispatch capacity contracts immediately, and stored energy cannot be delivered as planned. Market commitments may go unmet, and replacement capacity must be sourced elsewhere, resulting in lost revenue, potential penalties, and increased operational expenses.

In large-scale deployments, availability becomes more complex to manage. Thousands of battery modules operate simultaneously, each producing continuous temperature, voltage, and current data. These modules function as a coordinated system, in whichwhere small issues in one area can affectinfluence overall performance. As fleet size grows, operational oversight becomes more demanding.

Uptime is more than a maintenance metric. It directly affects revenue performance, capacity payments, and grid commitments. Even small disruptions can reduce dispatch capability before a full outage occurs. Preserving availability requires visibility that scales with system complexity.

The limits of reactive monitoring

Operational failures in BESS environments rarely begin as sudden outages. They often start as gradual shifts in temperature, voltage, or current that move systems toward instability while remaining within acceptable limits. These early changes can appear normal when viewed in isolation.

Most monitoring systems rely on predefined thresholds to detect abnormal conditions. An alert is triggered only after a value crosses a set boundary, confirming that a limit has already been breached. By the time an alarm activates, the underlying condition may have been developing for hours or days. The opportunity for intervention narrows.

Telemetry is often distributed across battery management systems, inverter controls, and environmental monitoring platforms, creating data silos across operational layers. Each system captures a portion of operational behavior, but signals are reviewed separately and correlated manually. This separation makes it difficult to see how conditions evolve across modules. Engineers spend valuable time assembling context rather than acting on it.

As deviations compound, risk increases. Capacity can drop offline, dispatch commitments may fail, and safety exposure rises. Reactive monitoring preserves awareness of failure, but does not preserve control.

Thermal Runway

Thermal runaway is one example of how small battery deviations can escalate when not addressed early. A gradual rise in temperature can accelerate internal reactions and generate additional heat. Without timely correction, this cycle can intensify and spread to neighboring cells. What begins as minor drift can trigger protective shutdown mechanisms designed to prevent damage. While necessary for safety, shutdown interrupts dispatch commitments and reduces available capacity. Lost availability affects revenue performance and may introduce regulatory and safety exposure. The longer that instability goes undetected, the greater the operational impact.

Predictive monitoring extends control

Predictive monitoring evaluates how operational signals change over time rather than reacting only after limits are breached. Temperature, voltage, and current readings are analyzed as evolving trends across battery modules, allowing engineers to see how conditions develop instead of viewing each signal in isolation. The value lies not only in collecting data, but in understanding how system behavior shifts as signals change together.

In large BESS deployments, thousands of modules generate high-frequency telemetry that reflects thermal and electrical conditions. When these signals are reviewed independently or only against static thresholds, gradual drift can appear routine. Evaluated within a shared time context, emerging patterns become visible across modules and clarify where intervention is required.

Time series data reflects current operating conditions, while historical data preserves baseline behavior and long-term performance trends. Comparing live readings against historical baselines distinguishes normal variation from early signs of degradation. By combining immediate visibility with long-term context, operators can intervene before instability propagates.

Real-time Analysis with InfluxDB

InfluxDB is purpose-built for time-series workloads that require high ingestion rates, scalable retention, and fast analytical queries. It captures continuous telemetry from distributed battery systems and organizes it using time-based indexing and columnar storage structures optimized for time-stamped data. Its value lies not only in storing operational signals, but in preserving query efficiency as data volume increases.

As BESS fleets expand, ingestion and query demand rise simultaneously. Temperature, voltage, and current streams must be written at scale while remaining immediately available for investigation. InfluxDB applies compression and retention policies that balance long-term historical context with storage growth. This design maintains visibility at scale without slowing down dashboards or investigative workflows.

Real-time analysis and historical comparison occur within the same execution path. Engineers can evaluate gradual drift and investigate emerging instability without exporting data to separate systems. Downsampling strategies preserve long-term trend visibility while keeping high-resolution data available for recent events. This unified architecture reduces operational overhead and preserves intervention windows under load.

Predictive monitoring in action

Siemens Energy uses InfluxDB to standardize predictive maintenance across distributed energy and battery storage operations. High-frequency sensor telemetry from production systems and battery deployments is ingested into a unified time-series platform that preserves both real-time visibility and long-term historical context. Its value lies not only in collecting large volumes of operational data, but in maintaining consistent access as systems expand across sites and regions.

Across more than 70 global locations and approximately 23,000 battery modules, continuous temperature, voltage, and performance signals are captured and stored within the same environment. Time-based indexing and scalable retention policies ensure that high-resolution data remains accessible for immediate analysis while preserving long-term degradation trends. This coordinated data architecture enables engineers to evaluate system behavior across modules rather than reviewing signals in isolation.

The verdict

BESS assets operate within narrow operational and financial tolerances where availability directly influences revenue, safety, and grid reliability. Reactive monitoring confirms when limits are crossed, but predictive monitoring preserves visibility into how conditions evolve before capacity is affected. As fleets expand and telemetry volume increases, infrastructure must ingest high-frequency signals, retain historical context, and return results without latency. When time-series architecture aligns with the structure of operational data, predictive maintenance scales with system complexity rather than breaking under it, preserving uptime across large BESS environments.

Ready to move from reactive monitoring to predictive control? Get started with a free download of InfluxDB 3 Core OSS or a trial of InfluxDB 3 Enterprise.

A Practical Guide to SCADA Security

Charles Mahler (InfluxData) — Tue, 03 Mar 2026 08:00:00 +0000

Critical infrastructure is under siege. The systems that control our power grids, water treatment plants, and oil pipelines weren’t designed for a connected world. This post covers what security measures teams need to understand and how time series monitoring can help turn SCADA’s weaknesses into a security advantage.

The stakes for SCADA security have never been higher

Somewhere right now, a programmable logic controller is opening a valve, adjusting a turbine’s speed, or regulating the chlorine levels in a city’s drinking water. These actions are orchestrated by Supervisory Control and Data Acquisition (SCADA) systems. They run power grids, water treatment facilities, oil and gas pipelines, manufacturing plants, and transportation networks.

For decades, these systems operated in relative obscurity. They sat on isolated networks, spoke proprietary protocols, and were managed by operational technology (OT) engineers who rarely crossed paths with the IT security team.

The convergence of IT and OT networks, driven by the demand for remote access, operational analytics, and cost efficiency, has dragged SCADA systems into a threat landscape they were never built to survive. The results have been dramatic. In 2015 and 2016, coordinated cyberattacks took down portions of Ukraine’s power grid, leaving hundreds of thousands without electricity. In 2021, the Colonial Pipeline ransomware attack shut down fuel distribution across the U.S. East Coast, triggering panic buying and fuel shortages.

These aren’t theoretical risks. They’re documented events, and they only represent the incidents that became public. The reality is that SCADA systems are being probed, scanned, and targeted every day, and many operators lack the visibility to even know it’s happening.

SCADA security challenges

Securing SCADA and industrial control systems is fundamentally different from securing a corporate IT environment. The assumptions, priorities, and constraints are almost inverted.

Availability Over Confidentiality

In IT security, the classic triad is confidentiality, integrity, and availability, usually prioritized in roughly that order. In OT, the priorities flip. A power plant cannot tolerate downtime. A water treatment facility cannot go offline for a patch cycle. The consequences of a disrupted industrial process aren’t a lost spreadsheet; they’re potential physical harm, environmental damage, or loss of life. This means that many standard IT security practices, such as aggressive patching, frequent reboots, and network scanning, can be dangerous or even impossible in OT environments.

Legacy Systems and Long Lifecycles

SCADA components often have operational lifecycles of 20 to 30 years. It’s not uncommon to find PLCs running firmware from the early 2000s, human-machine interfaces (HMIs) on Windows XP, or historians on unsupported database platforms. These systems were engineered for reliability and determinism, not security. Replacing them is expensive and operationally risky, so they persist despite the vulnerabilities.

Protocols Without Security

Modbus, DNP3, and OPC Classic are the workhorses of industrial communication, but they were designed in an era when network isolation was considered sufficient protection. Modbus, for instance, has no authentication, no encryption, and no way to verify the identity of a device sending commands. These protocols are deeply embedded in operational infrastructure and cannot be easily replaced.

The Air Gap Myth

Many organizations still believe their OT networks are air-gapped. In practice, true air gaps are rare. Remote access solutions, vendor support connections, shared file servers, USB drives, and even cellular modems on RTUs create pathways between networks.

Key strategies for SCADA security

Effective SCADA security is layered, OT-aware, and built around the operational realities of industrial environments. There is no single solution, but a combination of strategies dramatically reduces risk.

Network Segmentation

The foundation of SCADA security is proper network architecture. At a minimum, there should be a demilitarized zone (DMZ) between the corporate IT network and the OT network, with no direct traffic flowing between them. Within the OT network, further segmentation between supervisory systems, control systems, and field devices helps limit lateral movement.

Asset Inventory and Visibility

You cannot protect what you don’t know exists. Many organizations lack a complete, accurate inventory of their OT assets, including PLCs, RTUs, HMIs, historians, network switches, and communication links. Passive network discovery tools designed for OT environments can build and maintain this inventory without disrupting operations.

Access Control and Authentication

Every access point into the OT environment should require strong authentication, ideally multi-factor. Least-privilege principles should govern who can access what, and remote access should be tightly controlled, monitored, and time-limited. Shared accounts should be eliminated wherever possible.

OT-Aware Patch Management

Patching in OT requires a risk-based approach. Not every vulnerability needs an immediate patch, and not every system can be patched without operational impact. Organizations need a process that evaluates vulnerability severity in the context of their specific environment, tests patches in a staging environment where possible, and schedules maintenance windows that align with operational needs.

Deep Packet Inspection for Industrial Protocols

Traditional firewalls see Modbus traffic as TCP on port 502 and nothing more. OT-aware firewalls and intrusion detection systems can parse the actual protocol content to inspect function codes and register addresses to enforce policies.

Incident Response Planning

OT incident response is not IT incident response, the playbook must account for the physical consequences of containment actions. Isolating a network segment might stop an attacker, but could also trip a safety system or halt a process. Response plans need to be developed collaboratively between security teams, OT engineers, and plant operations.

Continuous monitoring for SCADA security

All of the strategies above are essential, but there’s a fundamental truth about SCADA security that defenders can exploit: industrial processes are inherently predictable.

A temperature sensor in a chemical reactor reports a value every second. A PLC cycles through its logic on a fixed schedule. A pump runs at a consistent speed. Network traffic between a SCADA server and its RTUs follows regular, repeatable patterns. This predictability means that anomalies like equipment failure, operator error, or a cyberattack create detectable deviations from established baselines.

This is where time series data becomes a security team’s most powerful tool.

Baselining Normal Behavior

By collecting and storing high-resolution time series data from sensors, PLCs, network flows, and protocol logs, you can build a detailed behavioral profile of “normal” for every asset and process in your environment. What does normal Modbus traffic look like between the SCADA server and PLC-07? What’s the typical temperature range for reactor vessel 3 during a batch run? How often does the engineering workstation initiate write commands?

With enough historical data, these baselines become remarkably precise, and deviations become immediately apparent.

Detecting Process Manipulation

An attacker who gains access to a SCADA system may try to subtly alter process parameters, such as changing a setpoint, opening a valve, or adjusting a chemical dosing rate. If you’re monitoring time series data from those processes, you can detect changes that fall outside historical norms.

Spotting Anomalous Network Behavior

Industrial network traffic is highly structured. By logging protocol-level metadata, you can detect unusual patterns. A “write multiple registers” command from an IP address that has only ever issued read commands is suspicious. A burst of DNP3 unsolicited responses at an unusual time deserves investigation. These signals are only visible if you’re capturing and analyzing this data.

Correlating Across IT and OT

The most sophisticated attacks traverse the IT/OT boundary. Detecting them requires correlating events across both domains on a unified timeline. For example, a failed VPN login attempt at 1:47 AM, followed by a successful login at 1:52 AM, followed by an unusual engineering workstation session at 1:55 AM, followed by a PLC configuration change at 2:03 AM. While each of these events in isolation might not trigger an alert, together, on a single timeline, the pattern is unmistakable. Time series data makes this correlation possible.

Why a time series database beats a SIEM or relational database for OT security data

If you’re convinced that this kind of monitoring is critical for SCADA security, the next question is where to store and analyze all this data. The three common options are a traditional relational database, a Security Information and Event Management (SIEM) platform, or a time series database like InfluxDB. For OT security data, the time series database wins decisively. Here’s why.

Data Volume

A single SCADA environment can generate enormous volumes of data. Consider a modest facility with 500 sensors reporting every second, 20 PLCs, a network tap capturing protocol metadata, and authentication logs from access points. That’s easily millions of data points per day, and larger environments generate orders of magnitude more.

Relational databases like PostgreSQL or MySQL were designed for transactional workloads: inserts, updates, deletes, and joins across normalized tables. They handle time series data poorly at scale. Write throughput degrades as tables grow, and time-based queries over millions of rows become expensive without careful indexing and partitioning, which creates operational complexity. SIEMs are built for log ingestion, but they’re optimized for text-based event logs, not numerical telemetry. Ingesting raw sensor data at one-second intervals into a SIEM is technically possible, but economically painful, as SIEM licensing is typically based on data volume, and the cost of ingesting OT data can be prohibitive. Many organizations end up sampling or aggregating data before it reaches the SIEM, losing the granularity needed for effective anomaly detection.

InfluxDB and other time series databases are built for this workload. They use storage engines optimized for high-volume writes of timestamped data and compressed, columnar storage that keeps disk usage manageable even at scale. InfluxDB can handle hundreds of thousands of writes per second on modest hardware.

Query Performance

OT security analysis is fundamentally time-focused. You need to answer questions like: “What was the average pressure in vessel 4 between 2:00 and 2:15 AM?” or “Show me all Modbus write commands to PLC-12 in the last 24 hours alongside the corresponding sensor readings.” or “Alert me if the rate of change of this temperature exceeds the 99th percentile of its 30-day historical distribution.”

In a relational database, these queries require careful SQL with window functions, CTEs, and often materialized views to perform well. The query language wasn’t designed for time series operations, and performance tuning is an ongoing burden.

SIEMs offer search languages that handle event correlation well but are awkward for continuous numerical analysis. Calculating rolling averages, derivatives, or statistical distributions over sensor data in a SIEM is possible but cumbersome.

Time series databases provide native query primitives for exactly these operations. InfluxDB includes built-in functions for windowed aggregation, moving averages, derivatives, percentiles, and histogram analysis. A query that would require 30 lines of carefully optimized SQL can often be expressed in a few lines with InfluxDB. This matters not just for convenience but for enabling security analysts and OT engineers to explore data and build detection logic without being database specialists.

Data Retention

OT security data has a natural tiered value structure. The last 24 hours of raw sensor data are extremely valuable for investigating an active incident. The last 30 days at full resolution are important for anomaly detection baselines. Data from six months ago is useful for trend analysis, but doesn’t need high granularity. Data from a year ago might only need hourly averages for compliance purposes.

Relational databases require you to manage this lifecycle manually by writing ETL jobs to downsample old data, archive tables, and manage storage. SIEMs typically offer hot/warm/cold storage tiers, but with limited control over how data is aggregated as it ages. InfluxDB has retention policies and downsampling built into the database itself. You can define policies that automatically downsample data from one-second to one-minute resolution after 30 days, then to five-minute resolution after 90 days, and delete raw data after a year. This happens transparently, without external tooling, and keeps storage costs predictable while preserving long-term visibility.

Moving forward

SCADA security is not a problem that can be solved with a single product, a one-time assessment, or a policy document. It requires sustained commitment to understanding your environment, monitoring it continuously, and building the organizational capacity to detect and respond to threats.

The good news is that the same characteristic that makes SCADA systems vulnerable, like their reliance on predictable, deterministic processes, is also what makes them uniquely defensible through data-driven monitoring. Industrial processes generate time series data that reveals anomalies clearly when you have the right tools to capture and analyze it.

A time series database like InfluxDB, paired with a well-designed collection pipeline and visualization layer, enables security teams to see their OT environment with a level of clarity that was previously impractical. Not as a replacement for network segmentation, access control, and the other foundational security measures, but as the monitoring layer that ties everything together and ensures that when something goes wrong, you know about it in seconds rather than weeks.

The "Now" Problem: Why BESS Operations Demand Last Value Caching

Suyash Joshi (InfluxData) — Thu, 26 Feb 2026 08:00:00 +0000

Battery Energy Storage Systems (BESS) represent one of the most unforgiving environments for real-time data. Unlike a passive asset, a battery is a complex electrochemical system where safety and revenue are determined by split-second decisions. In this context, “average” latency can become a serious problem. Performance depends entirely on one key question:

“What is happening right now?”

For grid operators, Energy Management Systems (EMS), and trading desks, this is the most critical question. To answer it, operations teams rely on dashboards that answer:

Safety & Health: What is the current State of Health (SoH) of my BESS operations? Is the site healthy, or are there active thermal alarms?
Bottlenecks: What is limiting performance right now? (Is it a Power Conversion System [PCS] derate, a specific rack, or a container-level issue?)
Revenue: What is the precise State of Charge (SoC) available for immediate dispatch?

The challenge: the “latest value” bottleneck

“Current state” dashboards create a punishing workload for standard time series databases. A single utility-scale site might generate 50,000+ distinct signals (high cardinality) from cells, inverters, and meters. To display a “Live View,” the database must repeatedly scan recent data on disk to find the most recent timestamp for every single one of those signals.

At the site level, this is difficult. At fleet scale with more assets, more concurrent users, and millions of streams, this “scan-for-latest” pattern becomes a crippling bottleneck.

The solution: Last Value Cache

InfluxDB 3 solves this architectural conflict with its built-in Last Value Cache (LVC). Instead of scanning historical data to compute the current state, LVC automatically caches the most recent values (or the last N values) in memory for your critical signals. This ensures that “current state” queries remain sub-millisecond (< 10ms) and consistent, regardless of write throughput or fleet size, bridging the gap between historical analysis and real-time situational awareness.

How to use InfluxDB’s Last Value Cache (LVC) in memory for BESS operations

1. Define Your “Hot” Signals

Don’t cache everything. Pick the specific high-leverage fields that power your “Current State” dashboards and safety alerts, for example:

Safety: Cell Temperature (temp_c), Voltage (volts), Alarm Severity (alarm_level)
Performance: State of Charge (soc), State of Health (soh), Inverter Mode (inv_state)
Ops: Comms Heartbeat (last_seen), Charge/Discharge Limits (p_limit_kw)

2. Design Your Keys

Choose the columns that define how operators slice the system. These will become your cache keys.

Best Practice: Match your dashboard filters. If your dashboard filters by site_id → container_id → rack_id, those are your keys.

Cardinality Note: Keep keys efficient. While InfluxDB 3 handles high cardinality exceptionally well, unnecessary keys (like a unique transaction_id per second) waste memory. Stick to asset identifiers.

3. Shape the Cache Behavior

Configure the cache to match your visualization needs:

count:
- Set to 1 for Gauges, Status Lights, and “Single Value” tiles.
- Set to 3–10 for “Sparklines” (mini-charts) where operators need to see the immediate trend (e.g., “Is voltage diving or stable?”).
ttl (time-to-live): Define when data becomes “stale.” If a sensor stops reporting, how long should the dashboard show the last value before switching to “Offline/Unknown”? (e.g., 30s for safety, 1h for capacity).

4. Create the Cache

Create the Last Value Cache using the UI explorer, HTTP API or the CLI.

influxdb3 create last_cache \
  --database bess_db \
  --table bess_telemetry \
  --token AUTH_TOKEN \
  --key-columns site_id,rack_id \
  --value-columns soc,temp_max,alarm_state \
  --count 5 \
  --ttl 30s \
  bess_ops_lvc

Key arguments:

Database name: bess_db
Table name: bess_telemetry
Cache name: bess_ops_lvc
Key columns: site_id, rack_id (field keys to cache)
Value columns: soc, temp_max, alarm_state (field values to cache)
Count: 5 (the number of values to cache per unique key column combination, range 1-10)
TTL: 30s (time duration until data becomes stale)
Token: InfluxDB 3 authentication token

5. The “Warm Cache” Advantage

Unlike a standard cache that starts empty, LVC in InfluxDB 3 is “warm” by default.

On creation: It instantly backfills from existing data on disk.
On restart: It automatically reloads the state.

Why it matters: Ops teams never see “blank” dashboards after a maintenance window. The system is ready the moment it comes back online.

6. Querying the Cache

Use standard SQL and last_cache() function that replaces complex analytical queries with a simple lookup.

influxdb3 create last_cache \
  --database bess_db \
  --table bess_telemetry \
  --token AUTH_TOKEN \
  --key-columns site_id,rack_id \
  --value-columns soc,temp_max,alarm_state \
  --count 5 \
  --ttl 30s \
  bess_ops_lvc

7. Architecture: Built for Scale Using InfluxDB 3 Enterprise

Last Value Cache can help separate heavy “writing” from “reading” workloads:

Dedicated Ingest Nodes: Handle the massive flood of 1Hz sensor data.
Dedicated Query Nodes: Host the LVC in memory to serve dashboards instantly.

influxdb3 create last_cache \
  --database bess_db \
  --table bess_telemetry \
  --token AUTH_TOKEN \
  --node-spec "nodes:query-01,query-02" \
  --key-columns site_id,rack_id \
  --value-columns soc,temp_max,alarm_state \
  --count 5 \
  --ttl 30s \
  bess_ops_lvc

The benefit: Heavy write loads (e.g., a fleet-wide firmware update logging millions of events) will never slow down the control room’s live view.

The value of LVC

In BESS operations, latency isn’t just a delay; it’s a risk. InfluxDB 3’s Last Value Cache eliminates that risk by serving the “current state” of your entire fleet instantly from memory, removing the need for complex external caching.

When you’re ready to start building, download InfluxDB 3 Enterprise, or contact us to talk about running a proof of concept.

What Is Predictive Analytics? A Complete Guide for 2026

Company (InfluxData) — Tue, 24 Feb 2026 08:00:00 +0000

In simple terms, predictive analytics is a form of analytics that tries to predict future events, trends, or behaviors based on historical and present data. You can achieve this goal in different ways, each involving trade-offs between accuracy and cost.

Why is predictive analytics important?

Predictive analytics enables organizations to be more efficient and accurate in how they plan for the future. The end result of a properly implemented predictive analytics system will depend on the industry, but at a high level, here are some common benefits:

Improved Strategic Decision-Making

Predictive analytics provides insight into future trends, so business leaders can make better decisions faster rather than relying on reactivity.

Increased Operational Efficiency

Using predictive analytics can help businesses improve their profit margins and efficiency by predicting equipment failures and reducing downtime.

Improved Risk Management

By looking at historical data where things went wrong, a business can reduce its risk by finding data that correlates with negative outcomes and avoiding them proactively. An example would be a bad investment in the finance industry.

Happier customers

Predicting potential churn and reaching out to customers, or ensuring items are in stock by having more accurate predictions for inventory management help enhance customer experience.

How does predictive analytics work?

The end goal of predictive analytics is to make accurate predictions based on historical data. Here is a general outline of the process for building a predictive analytics system:

1. Determine the goal for the project. The first step is to identify the problem or opportunity you are trying to address via predictive analytics. Define your goals and success metrics upfront.

2. Organize and collect data. The next step will be gathering the data to build your predictive analytics model, as well as the pipeline that will send fresh data to your model for generating predictions. This will typically be a combination of public data similar to your own, 3rd-party data relevant to your use case, and your own unique business data for fine-tuning your model.

3. Process data. Once you have your data, one of the biggest challenges is often processing and cleaning it so it’s ready for your model. This can involve removing invalid data, filling in missing data, or transforming data into a standard format.

4. Develop a predictive analytics model. Now that your data has been collected and cleaned, you are ready to actually develop your predictive model. The model you use will depend on your business requirements, including accuracy requirements and the type of modeling you will be doing.

A predictive model can be used for trend detection, classification, clustering, and more. You can create these models using statistical methods or modern machine learning techniques.

5. Validate results. Creating and deploying your model is just the first step; once the model is live, you will need to validate the results to confirm it works as expected. This generally involves testing against a separate dataset for accuracy, as well as running the model against live production data and evaluating the results based on the output. If the results aren’t as good as desired, you may need to return to the previous steps and modify factors like how data is processed and the type of model used.

6. Deploy to production. If your predictive analytics model produces accurate, valuable results, you can now deploy it to production, where people will actually use the results. The system may need a human to confirm the action, or it may be fully automated, taking action solely based on the model.

7. Update and improve the model over time. Predictive analytics isn’t a one-time deal. You will want to constantly feed your model recent data so it stays up to date and can be aware of potential changes that need to be integrated. Typical tasks would involve retraining the model, adjusting parameters, or providing it with additional data to improve accuracy. The entire system can also be fine-tuned over time to be more efficient and affordable.

Predictive analytics use cases

Predictive analytics are useful across almost every industry, but let’s take a look at a few specific examples where predictive analytics are particularly valuable. An ideal use case for predictive analytics is any situation where data is relatively easy to collect and having more accurate predictions will generate a significant business impact, such as revenue or cost reduction.

Manufacturing

In the manufacturing sector, predictive analytics can be used to predict and prevent machinery malfunctions before they occur. This reduces maintenance costs and improves factory efficiency of factories, resulting in higher profit margins.

Healthcare

Governments and businesses both use predictive analytics to improve the healthcare industry. Governments create predictive models to try to predict and prevent the spread of diseases and also determine investments in healthcare programs. Hospitals can use predictive models to look at patient medical records to create personalized treatment plans.

Marketing

Predictive analytics can be used for marketing purposes to predict trends in consumer demand, improve customer engagement to prevent churn, and improve sales by recommending products customers might like based on their past purchases compared to those of similar customers.

Supply Chain Management

Predictive analytics can help with supply chain management by forecasting changes in product supply and demand driven by factors such as time of year or location.It can also be used to optimize logistics and manage risk.

Finance

The finance industry uses predictive analytics in a number of ways, ranging from predicting stock prices to detecting fraudulent transactions. Banks can use predictive analytics to assess loan applicants’ risk by comparing historical data with the applicant’s personal history.

Predictive analytics challenges

While predictive analytics can offer many business benefits, implementing it can be challenging, especially if a company lacksin-house expertise or infrastructure. Here are some of the key roadblocks to consider when getting started.

Data Quality

To make accurate predictions, you will need a large volume of high-quality data relevant to your predictive analytics use case. This means you need to have a way to collect data and store it in a long-term format that is easy to access for teams creating predictive analytics models.

Integration with Legacy Systems

Many established businesses will have systems that may not be seamlessly integrated. This means engineering effort will be required to ensure that data is not siloed and that the predictive analytics team can access the systems and data they require.

Accuracy of Results

The biggest challenge with predictive analytics will be creating a model that produces results accurate enough to justify the investment in creating them and that drives business value.

This will require not only the initial creation of the model but also constant updates with new data to keep it accurate as conditions change.

Hiring Talent

All of the above problems require highly skilled employees to be solved. These skills are in demand across many industries, making it difficult to attract and retain the workers needed to implement a predictive analytics system.

Security

Another challenge with predictive analytics is ensuring that all the new data collected and stored is secure. This data can contain sensitive information about customers or about your business, so security must be a top priority.

Predictive analytics techniques

There are a number of models available for generating insights via predictive analytics. The type of model to use for your organization depends on the data you are working with, as well as factors such as the cost to develop the model and your accuracy requirements. Let’s take a look at some of the most common predictive analytics techniques and models.

Machine Learning/AI Models

In the past, classical statistical models have dominated predictive analytics and forecasting because of their ease of interpretation, lower computational costs, and accuracy. However, in recent years, ML/AI-based models have begun to surpass traditional forecasting methods in accuracy. They also offer the benefit of being easier to generalize across different predictions and of requiring less fine-tuning by highly trained statisticians.

Time Series Models

Time series models are used to analyze temporal data and forecast future values. They are particularly useful when data shows sequential patterns or seasonality, such as stock prices, weather patterns, or sales data.

Time series models are ideal for data that has seasonal variations and time-based dependencies, making them useful for forecasting.

Some downsides of time series models are that they can struggle when the data isn’t at regular intervals and may assume past trends will continue, which can make them inaccurate at predicting drastic changes.

ARIMA and exponential smoothing are examples of time series models. An easy way to start testing these models for predictive analytics is to use a library like Python Statsmodels.

Regression Models

Regression models predict a continuous outcome variable based on one or more predictor variables. They are widely used in predictive analytics, from predicting house prices to estimating stock returns.

Regression models are useful for providing results that are easy to interpret and for identifying clear relationships between variables. Some downsides of regression models are that they do require a decent level of statistics knowledge and can struggle with non-linear relationships and datasets with many variables.

Linear and logistic regression are examples of regression models. You can get started with regression models using the Python scikit-learn library.

Decision Tree Models

Decision tree models make predictions by learning simple decision rules from the data. They can be used for both regression and classification problems. Decision tree models offer results that are easier to understand than those from machine learning models. A challenge is that they can be easily over- or underfit and be affected by small changes in the data.

Gradient Boosting Model

Gradient boosting involves creating an ensemble of prediction models, typically from decision tree models. This method can be extremely accurate and has been used in recent years to win many machine learning competitions.

Gradient boosting is good at providing accurate predictions for data with non-linear relationships between variables and datasets with high dimensionality.

One weakness is that they can be overfit when they aren’t tuned properly and are more of a black box compared to traditional statistical models. XGBoost and LightGBM are libraries that can be used to create gradient boosting models.

Random Forest Models

Random forests are similar to gradient boosting in that they are ensemble models that use decision trees for making predictions. The main difference is that gradient boosting models generally use far more decision trees, and they are also trained sequentially so that errors from previous trees can be corrected.

In comparison, random forest decision trees make predictions independently, and then the final prediction is created by aggregating those predictions. This makes the results easier to interpret because each decision tree’s prediction can be analyzed. You can test out random forest models on your data using a library like scikit-learn.

Clustering Models

Clustering models, such as k-means clustering, can be used to group data points. While this is generally used for data analysis, these clusters can also serve as input features for predictive models like the ones mentioned above.

Cluster modeling can help identify hidden patterns or relationships in your data, but to work, it requires a way to measure how similar data points are, and the number of clusters ‌must be chosen ahead of time.

Future trends in predictive analytics

The predictive analytics landscape is changing rapidly as technology advances and impacts all industries. Here are a few trends to look out for in the future:

Increased demand for real-time data. To get the most accurate results, models need to be updated as frequently as possible so they aren’t out of sync with reality. This means that real-time data and systems that support it will become increasingly important.
Prescriptive analytics. The term prescriptive analytics refers to the next step beyond predictive analytics. This involves taking action based on a predicted outcome before it occurs to try to influence the outcome.
Synthetic data. Data is the key to making accurate predictions. The problem is that many businesses haven’t collected the data they need. A number of tools have been created to generate “synthetic” data, which can help get a predictive analytics system off the ground using artificial data that mimics the use case.
Further adoption of machine learning and AI. While most businesses still rely on traditional methods for prediction, cutting-edge practitioners are using ML/AI to win competitions because of its accuracy.
Easier to use predictive analytics tools. Currently, implementing and using predictive analytics requires specialized skills. But domain knowledge is very important for making accurate predictions.

Future tools will focus on usability and enabling non-technical users to make predictions based on their data. This will make implementation more affordable and drive more business value.

Best practices

Here are some helpful tips for using predictive analytics.

Have a well-defined objective. Predictive analytics can only generate value when it influences a decision, and hence, the why should be the first thing followed by the model. Without a goal, you’ll maximize the things that make no difference. To implement this, you must clearly state what you want to predict, where you will apply the prediction, and what action you will take.
Focus more on feature engineering than model complexity. Features are used to convert raw data into signals that the model can learn, and this step can be what makes the difference in determining success, more than the algorithm used. To do this effectively, design domain-aware features such as rolling averages, lagged values, and behavioral features like frequency and recency.
Measure models based on business impact. Conventional measures such as accuracy may be misleading, particularly in skewed problems. It is significant because the technically correct model can be expensive or hazardous to implement. Use measures of actual trade-offs, like accuracy and accuracy of fraud detection, or average misplacement of demand forecasting.
Choose an easy, performance-dependent model. Complex models may be appealing; however, they are more difficult to maintain, debug, and explain. This is important in production situations where stability and interpretability are paramount. It is better to start with baselines and simple models, and add complexity only as performance improves.
Provide quality, time-accurate data. Predictive models use patterns in past records, and poor quality or poorly ordered records can lead to misleading results. Problems such as lost values, data leakage, or irregular timestamps may only inflate model performance during testing but not in production.

Common pitfalls to avoid in predictive analytics projects

Overfitting the Model

Overfitting occurs when a model fits noise rather than any general patterns, usually because of too much complexity or too little data. This is important because these models are useful for training data but not for new data.

An example of this is that a deep neural network trained on a small sample of customers might work flawlessly at elucidating the past, but would not help predict what customers would purchase in the future, whereas a simpler model would be more generalizable.

Data Leakage

Data leakage occurs when the information of the future accidentally affects the model during training. This will happen when it has features with data that cannot be known at prediction time, achieving unrealistically high test performance but failing in practice.

One such example is the use of the account closed date or an order completion status as an input into the churn or demand prediction model, which makes the model seem very accurate, but is not usable in practice.

Using the Wrong Evaluation Metrics

Accuracy alone can be a bad way to measure model performance, especially for use cases where positives are rare and costly when missed. An example would be fraud detection, a model that simply classifies all transactions as non-frauds would be very accurate(due to over 99% of transactions being legitimate), but in reality it’s still missing every case of fraud. For use cases like this teams need to use metrics that track actual business impact when evaluating their models.

Ignoring Changes in Data Patterns

Predictive models assume that future data will behave like past data; however, in reality, systems continue to evolve. This is particularly problematic in areas such as retail or finance, where seasonality, promotions, or changes in user behaviour often change.

FAQs

Predictive Analytics vs Predictive Maintenance

Predictive analytics is a broad field that uses statistical algorithms, machine learning, and data to anticipate future events across many domains. It identifies patterns in historical and current data to predict future trends, behaviors, and activities. Predictive analytics is used across industries such as finance, healthcare, and marketing to inform decision-making and develop proactive strategies. Predictive maintenance, on the other hand, is a specific application of predictive analytics in maintenance and asset management. It uses predictive analytics techniques to anticipate when equipment might fail or require maintenance. By analyzing data from sensors, logs, and historical maintenance records, predictive maintenance models can forecast equipment failures before they happen. The goal is to perform maintenance in time to prevent failures, improving efficiency and reducing downtime. In short, predictive maintenance is a subset of the broader predictive analytics ecosystem.

Traditional Statistical Models vs Machine Learning and AI Models for Predictive Analytics

More traditional techniques, such as regression models and decision trees, have been used for decades in predictive analytics. This is due to their simplicity, lower computational requirements, and ability to show the relationship between specific variables and the impact of changing them on business outcomes. In recent years, AI/ML techniques like neural networks and gradient boosting have grown in popularity for predictive analytics use cases. The primary reason is that ML techniques can perform better with higher-dimensional data, where relationships among numerous variables are harder to define. These AI/ML models can learn from data without explicit tuning and can uncover relationships between variables that aren't obvious, resulting in higher accuracy. Some downsides of AI/ML for predictive analytics are that they tend to require more hardware for computation and are harder to interpret in terms of how they produce results, in some ways acting as black boxes.

Node-RED Dashboard Tutorial

Community (InfluxData) — Wed, 18 Feb 2026 08:00:00 +0000

If you’re already familiar with Node-RED, you know how useful it is for automation. This post is a guide to getting started with the Node-RED dashboard 2.0. We’ll cover how to install the Node-RED dashboard 2.0 nodes and provide examples of how to create a graphical user interface (GUI) for your automation.

What is Node-RED?

Node-RED is a programming tool built on Node.js that lets you create automated workflows with minimal code. It wires different nodes together, with each node performing a specific function that links them to create a flow that carries out an automation task (e.g., switching off the light in a room or closing a door).

Prerequisites

We assume you’ve already installed and set up Node-RED. If that isn’t the case, here are some guides that can help you achieve that a few different ways:

Node-RED dashboard installation

The first step in the process is installing the dashboard module in Node-RED.

In the browser’s Node-RED window, click on the Menu icon at the top right corner of the page, find Manage Palette on the menu items, click Install, and search for @flowfuse/node-red-dashboard. Install it and make sure the module reads @flowfuse/node-red-dashboard.

After successful installation, all the Dashboard 2.0 nodes will appear in the palette section. Each dashboard node provides a widget that you can display in a user interface (UI) (e.g., a gauge, chart, or button).

Creating a user interface

In this section, we’ll walk through how to create a dashboard UI using the Dashboard 2.0 nodes on Node-RED. But first, let’s understand the dashboard hierarchy.

Dashboard Hierarchy

Dashboard 2.0 uses this hierarchical structure:

Base: Defines the base URL for your dashboard. The default is /dashboard.
Page: Individual pages that users can navigate to.
Theme: Offers different options for styling the dashboard.
Group: Collections of widgets within a page
Widget: Individual UI elements, like buttons, text, charts, and others.

We use pages and groups to arrange the UI in the Node-RED Dashboard 2.0. Pages are the main navigation section that hold or display different groups, which separate a page into several sections. In each group, you organize your node widgets (buttons, texts, charts, etc.)

Now let’s create your first widget.

Step 1: Grab a button node

Look at your palette on the left side and find the button node (It’s in the dashboard 2 section). Click and drag it to your workspace (the big grid area in the middle of your screen).

Step 2: Open the configuration

Double-click on the button you just placed. A configuration window will pop up with a bunch of options.

Step 3: Create a group

See Group near the top? Click the pencil icon next to the dropdown. This edits the default group Node-RED created when you added the widget. Give it a name like “My Controls.” If you want to create a completely new group instead, click the plus sign next to the pencil icon.

Step 4: Create a page

Now, in that same group window, you’ll see a field that says Page. Click the pencil icon next to it and then give the page a name, maybe “Dashboard,” for your first one. Now click Add ( or Update if you’re editing the default, as in my case).

Step 5: Finish up

You’ll be back at the group window. Click Add (or Update) there as well, and you should be returned to the button configuration window. Click Done, and everything should be set.

Now we have successfully created our first page and group. The next step will be displaying something on the user interface.

In this example, we want to create a button that displays text when clicked on.

Add a text node from your palette and place it near your button.
Wire them together. You can do this by dragging from the button’s right port to the text node’s left port.

Double-click the text node and set the Group to match your button’s group (in my case, “My Controls”). Also, give a name and a label, then click Done.

Next, double-click the button, scroll to Payload, type “Welcome to Dashboard 2.0!”, enter a name and a label like “Click Me,” and click Done.
Now click the red Deploy button in the top right corner.

To view the dashboard UI, follow this URL: http://localhost:1880/dashboard or http://Your_RPi_IP_address:1880/dashboard, where Your_RPi_IP_address is the address of the Raspberry Pi machine you’re using, 1880 is the port where Node-RED is exposed, and /dashboard displays the dashboard user interface.

If everything works correctly, you’ll see the same window shown below.

When you click the button, the “Welcome to Dashboard 2.0” text will appear as shown in the image below.

You might see a light theme background. We’ll get to how to change themes later in the post.

More examples of widgets

Let’s create a simple dashboard example with two tabs and UI elements (widgets) in each.

Creating Additional Pages

Open the Dashboard 2.0 sidebar (right side of your editor) and click the + Page button at the top.

This will create a new page and pop up a window with options to edit the page’s properties (such as name, path, and others). Remember, you can also create pages when configuring a widget (as we did earlier).

Building an interactive data visualization

Now, we’ll create a slider that controls both a gauge and a chart in real-time. This is the setup:

Step 1: Drag a slider, gauge, and chart node into your workspace. Step 2: Double-click the slider, set min to 0, max to 100, and assign to a new group on your second page, which you just created (mine is “Monitoring Dashboard”).

Step 3: Next, double-click the gauge. Assign it to the same group and range of 0-100, and add a color segment (green 0-30, yellow 30-70, red 70-100).

Step 4: Next, configure the chart. Same group and set Type to “Line.”

Step 5: After this, you need to wire the gauge and chart to the slider, as shown in the image below.

Step 6: Deploy and go to your dashboard UI (http://localhost:1880/dashboard or http://Your_RPi_IP_address:1880/dashboard). Step 7: In your dashboard UI, navigate to the next page. Click the hamburger icon in the top left corner, and you will see a list of your pages. Select your second page (mine is “Monitoring Dashboard”).

Step 8: On your second page, notice the initial state of your dashboard.

Step 9: Move the slider on your dashboard and watch everything update instantly (the gauge changes color, the chart plots, and Z the values).

Connecting to real weather data

Now, let’s enhance our example by connecting to a real data source. In this example, we would fetch real weather data and display it on our dashboard.

Step 1: Go to your Manage Palette on your Menu, search and install node-red-node-openweathermap (Like we did with @flowfuse/node-red-dashboard in the previous example).

Step 2: Get an API Key from http://openweathermap.org (New keys take up to two hours to activate, so be patient if you’re just signing up).

Step 3: Drag openweathermap node to your workspace, double-click it, paste your API key and enter your city and country (e.g., “New York City, US”), and then click Done.

Step 4: Next, drag an inject node to your workspace, double-click it, and set Repeat to “interval.” Also, check “Inject once after” so it runs on startup. Then wire the inject node to your openweathermap node.

Step 5: Drag a debug node, wire it to the openweathermap node, and Deploy. Open the Debug panel (in the right sidebar, bug icon). You’ll see the weather data structure showing what’s available.

Step 6: Next, add three function nodes to extract data:

Double-click the first function node, name it “Get Temperature,” and add the code below:

msg.payload = msg.payload.tempc; 
return msg;

Name the second “Get Humidity” and add:

msg.payload = msg.payload.humidity; 
return msg;

Name the last function “Get Conditions” and add:

msg.payload = msg.payload.description;
return msg;

Wire all three functions from the openweathermap node.

Step 7: Next, add display widgets:

Add two gauge nodes for temperature (set unit as “°C”, range -10 to 40) and humidity (% as unit, range 0-100).
Add one text node for the weather conditions.
Assign all to the same group (preferably a new group and page) and wire each function to its corresponding display widget.

Step 8: Finally, deploy and visit your dashboard UI.

Now, you’ve gotten a live weather dashboard updating every 10 minutes!

Dashboard theme and styling

By default, the Node-RED dashboard comes with a light theme, but you can also customize it. To edit the theme on your UI, open the Dashboard 2.0 sidebar, click on the Theme section, and you can:

Customize themes and colors
Set custom fonts
Adjust spacing and sizing

After you’re done, don’t forget to deploy so you can view your changes.

Common issues and fixes

While following this tutorial, here are some common hurdles you might encounter and how to fix them:

If your dashboard fails to open, look at the URL. Try using http://localhost:1880/dashboard, otherwise, use your PI’s IP instead.
If your widgets are not appearing on your dashboard, ensure that they’re connected to a group and a page before deploying.
If OpenWeatherMap returns “Invalid API key,” just wait a bit (activation can last two hours). Clicking buttons, but no response? Ensure your nodes are well-connected.

Wrapping up Node-RED dashboard

The aim of this guide was to provide basic knowledge of how the Node-RED dashboard 2.0 works on Raspberry Pi. I believe, with all the examples we covered in this post, you should have an idea of what you want to do next with the Node-RED dashboard on your journey to an automated life.

Node-RED Dashboard FAQs

What is the difference between Node-RED Dashboard 1.0 and Dashboard 2.0?

Dashboard 2.0, published by FlowFuse under the package @flowfuse/node-red-dashboard, is a ground-up rewrite of the original Node-RED dashboard. It introduces a new hierarchy (Base, Page, Theme, Group, Widget), improved theming and styling controls, and a more modern component set. If you're starting a new project, Dashboard 2.0 is the recommended choice, as it is actively maintained and better suited for complex, multi-page UIs.

Can I run the Node-RED dashboard without a Raspberry Pi?

Yes. Node-RED runs on any system that supports Node.js, including Windows, macOS, and Linux. The dashboard is accessed through a browser at http://localhost:1880/dashboard regardless of which machine Node-RED is installed on. Raspberry Pi is a popular choice for home automation projects, but it is not required to use the Node-RED dashboard.

Why are my Node-RED dashboard widgets not showing up?

The most common reason widgets don't appear is that they haven't been assigned to both a Group and a Page before deploying. Every widget in Dashboard 2.0 must be linked to a group, which must itself be linked to a page. Double-click the widget node to verify those assignments, then click the red Deploy button and refresh your dashboard URL.

How do I display live data from an external API in the Node-RED dashboard?

Use an inject node set to a repeating interval to trigger the flow on a schedule, then connect it to a data-source node (such as node-red-node-openweathermap for weather data). Wire one or more function nodes after the data source to extract the specific fields you need from the payload, then connect each function node to a corresponding display widget — such as a gauge or text node — on your dashboard. Deploy the flow and the dashboard will update automatically at each interval.

How do I add multiple pages to my Node-RED dashboard?

Open the Dashboard 2.0 sidebar on the right side of the Node-RED editor and click the + Page button to create a new page. You can also create a page directly when configuring any widget node — click the pencil icon next to the Page field to edit or create one inline. Once pages are created, users can navigate between them via the hamburger menu in the top-left corner of the dashboard UI.

How do I change the theme or colors of my Node-RED dashboard?

In the Dashboard 2.0 sidebar, navigate to the Theme section. From there you can customize colors, set custom fonts, and adjust spacing and sizing. The default is a light theme, but dark and custom themes are supported. After making changes, click Deploy to apply them to your live dashboard.

What types of widgets are available in Node-RED Dashboard 2.0?

Dashboard 2.0 includes a range of UI widgets covering inputs (buttons, sliders), displays (gauges, charts, text), and layout controls (groups, pages). Gauges support color-coded segments, charts support line and other types, and sliders can drive real-time updates to other widgets. All widgets appear in the palette under the "dashboard 2" section after installing @flowfuse/node-red-dashboard.

From Legacy Data Historians to a Modern, Open Industrial Data Stack

Suyash Joshi (InfluxData) — Thu, 12 Feb 2026 08:00:00 +0000

We recently sat down with founder and principal consultant at recultiv8, Coenraad Pretorius, who drew on his years of data engineering experience in the manufacturing and energy sectors to share key industrial IoT insights. In this article, I list the top takeaways; you can also watch the full webinar recording here.

The challenge with traditional data historians

Industrial systems generate large volumes of time series data from machines, sensors, and control systems. Historically, this data has been managed using proprietary data historian platforms.

These systems often lead to the following challenges:

Complexity: Traditional stacks involve many tightly coupled components: SCADA systems, OPC servers, historians, data extraction tools, and analytics layers. Each layer requires specialized skills, making systems difficult to debug, extend, or modernize.
High cost: Per-tag licensing, annual maintenance fees, and specialized training significantly increase the total cost of ownership, particularly as systems scale.
Slow time to insight: Extracting and analyzing data often takes days or weeks, delaying decisions and limiting optimization opportunities.
The analytics gap: Traditional historians prioritize data storage, not data analysis. Common pain points include proprietary query languages, reliance on Excel exports, overloaded BI integrations, and additional licensing for advanced features. As a result, time to action is measured in days or weeks rather than hours, which is an unacceptable delay for modern industrial operations.

Data Historian Technical Architecture

A modern, open architecture: edge + cloud

To address these limitations, Coenraad presented a modern architecture built around InfluxDB 3, open source tooling, and cloud analytics. The core idea is a clear separation of responsibilities that leads to improved performance, security, cost efficiency, and scalability while keeping systems simpler and easier to operate.

Edge systems handle real-time ingestion, short-term storage, and operational dashboards close to the data source.
Cloud systems handle long-term storage, historical analysis, and advanced analytics without impacting operational performance.

Modern IIoT Technical Architecture

Example from Coenraad’s case study

Typical deployment setup

Four OPC UA servers
10k+ tags
Windows-based servers
Telegraf running as Windows service

Configuration approach

Split config files (agent, inputs, outputs)
Custom Starlark processor for schema management
Environment variables for cloud credentials

Result: Rapid implementation of the modern data stack using open source solution resulted in saving $70k (once off) and $5 (annually).

Why this approach works

This modern stack delivers several practical benefits:

Simpler systems built with familiar tools like SQL and Python that most developers are familiar with.
Faster dashboards move from multi-second load times to near instant response as detailed in this blog post.
Lower costs are incurred by replacing proprietary licensing with open source and consumption-based services.
Flexible data pipelines use Telegraf to ingest data from industrial protocols such as OPC UA, MQTT, and Modbus into InfluxDB Core with optional streaming to the cloud.

Recap

The difference is fairly cut and dry: traditional data historians often limit agility and slow down insights, while modern industrial data stacks focus on speed, openness, and maintainability by separating edge operations from cloud analytics and using familiar, developer-friendly tools. For industrial and IIoT teams, modernizing the data pipeline is now foundational. To learn more, read the Teréga case study and connect with our community in the InfluxDB forums.

How Network Operations Teams Use InfluxDB to Solve Network Monitoring Gaps

Mike Devy, Patrick Oliver (InfluxData) — Thu, 05 Feb 2026 08:00:00 +0000

Organizations are starting to question whether the value they get from traditional Network Monitoring Systems (NMS) justifies the budget they’ve locked into them.

On the technical side, network operations teams are dealing with more complexity than ever. Environments are dynamic, traffic patterns shift quickly, and the cost of outages keeps rising. Meanwhile, many traditional platforms haven’t kept pace. Their data pipelines and discovery workflows lag behind how modern networks actually behave. At the same time, pricing and licensing changes are making NMS and Network Performance Management (NPM) solutions even more costly. SolarWinds is a clear example: after its acquisition by Turn/River and shift to a subscription-based licensing model, users have reported a price increase of over 100%.

This is exactly where one of our largest enterprise customers found themselves, anonymous here due to regulatory requirements. They found that their NMS had blind spots that no amount of tuning could fix. Rather than continue pouring budget into SolarWinds to chase diminishing returns, they reallocated spending to implement a network monitoring solution built around InfluxDB. It closed the gaps immediately, restored the visibility they needed for day-to-day reliability, and gave the organization room to decide what comes next.

Below are a couple of the main networking monitoring challenges this team faced, why their NMS couldn’t address them, and how they used their InfluxDB-centric solution to close their network monitoring gaps.

Network spike detection

The operations team kept seeing Virtual Fabric Drops (VFDs) and intermittent link flaps on a 400 Mbps data center interconnect, but nothing in their NMS showed utilization anywhere near the levels that should trigger them. In fact, it appeared the link never broke ~365 Mbps.

The underlying issue was short, high-intensity traffic spikes that the NMS could not capture. With a five-minute polling interval, each window was averaged into a single utilization value. Spikes that lasted only a few seconds never aligned with the polling timestamps and were smoothed into what looked like normal traffic.

The team identified the real pattern only after collecting 1-second metrics from their Arista switches with Telegraf and storing them in InfluxDB. At that resolution, the spikes were obvious and lined up exactly with the VFD events. Their Cisco switches, limited to 30-second polling under SolarWinds, simply couldn’t provide the granularity needed to reveal this behavior.

CPU monitoring granularity

The operations team was seeing intermittent performance issues on a Palo Alto firewall, but nothing in their monitoring system indicated CPU saturation. Throughput and latency symptoms suggested load problems, yet the reported CPU utilization stayed around 50%, well below any alarm thresholds.

The underlying issue was the way the NMS collected and reported CPU metrics. The firewall has separate data-plane and control-plane CPUs, and the platform’s default behavior was to average them. In the incident in question, the data-plane CPU was at 99% while the control-plane CPU sat at 2%, and the averaged value masked the data-plane saturation entirely. As a result, the primary indicator of forwarding stress never surfaced.

When the team pulled per-CPU metrics into InfluxDB using Telegraf, the data-plane spikes were immediately visible and aligned with the observed performance degradation. From there, they set independent alerts for each CPU so data-plane saturation would be detected directly. While the NMS could have been customized to approximate this view, InfluxDB provided the necessary granularity by default, making the issue straightforward to diagnose and monitor going forward.

Dynamic VIP monitoring

The team noticed that Virtual IP (VIP) metrics were incomplete or out of date, and some newly created services weren’t showing up in their monitoring at all. The gaps appeared random, but they pointed to a visibility issue rather than an application problem.

The root cause was straightforward. Their NMS couldn’t automatically discover or track new VIPs as they were created, moved, or retired. Each VIP had to be added manually, and anything not configured manually wasn’t monitored. In a dynamic environment, that meant missing data and inconsistent coverage.

Once the team switched to an InfluxDB-centric approach, the issue went away. Telegraf pulled VIP information directly from their AVI load balancer, and each VIP, along with its metrics, was written to InfluxDB as soon as it became available. Monitoring kept pace with the environment without any manual steps. This was especially useful in deployments where VIPs changed frequently, reducing overhead and ensuring complete, up-to-date visibility across the entire set of VIPs.

How InfluxDB+ addresses NMS observability gaps

Most NMS platforms miss the same categories of data: short-lived spikes, per-component metrics, dynamic objects like VIPs, and anything outside their predefined device models. An InfluxDB-centric stack fills those gaps without replacing your existing tools.

Key Components of the Stack

Telegraf — Collects high-resolution metrics from devices across the network.
InfluxDB 3 Enterprise — Ingests telemetry at scale and provides fast queries for both recent and historical data.
Grafana — Visualizes the data and supports operational dashboards and alerting.

Telegraf acts as the universal collector. It pulls metrics, every second or faster, from routers, switches, firewalls, load balancers, storage systems, and virtual infrastructure using SNMP, gNMI, and vendor APIs. It captures interface counters, per-CPU usage, packet drops, latency, queue depth, and other operational signals. Telegraf streams all of this telemetry—thousands of series from across the environment—directly into InfluxDB at full fidelity.

InfluxDB 3 is the core of the stack. It ingests high-resolution telemetry at scale and provides fast access to the recent data needed for dashboards, alerts, and operational workflows. At the same time, it retains full-fidelity history at low cost, giving teams a single place to analyze both real-time conditions and long-horizon trends. The processing engine supports real-time evaluations and, when paired with tools like Grafana, it delivers continuous, high-resolution visibility across the entire environment.

Future proofing your network monitoring stack

If there’s one lesson from this customer’s experience, it’s that network monitoring is shifting fast. Networks are more distributed, more dynamic, and far more dependent on real-time signals than traditional NMS platforms were built to handle. Polling cycles, rigid device models, and closed data pipelines simply can’t deliver the visibility modern operations teams need.

InfluxDB 3 + Telegraf gives operations teams a way to work past those constraints. New devices, protocols, and metrics can be onboarded immediately, without waiting for vendor updates. And because the platform stores full-fidelity telemetry inexpensively, teams keep both the real-time signals they need for operations and the long-term history required for deeper analysis.

That combination of real-time visibility into high-resolution telemetry and cost-effective retention supports the broader remit of modern network operations teams. They are responsible not only for day-to-day reliability but also for the long-term work that depends on complete data: capacity planning, drift detection, anomaly identification, and cross-system correlation.

In short, if you are running into similar visibility gaps or preparing for a more complex environment, you have options. InfluxDB can fill specific weak spots, operate alongside your existing NMS as a high-resolution telemetry layer, or replace the legacy platform entirely. Unlike traditional NMS tools, it doesn’t lock you into a fixed model or licensing scheme. The stack scales with your network instead of constraining it.

How to Use Pandas Time Index: A Tutorial with Examples

Company (InfluxData) — Thu, 05 Feb 2026 08:00:00 +0000

Time series data is everywhere in modern analytics, from stock prices and sensor readings to web traffic and financial transactions. When working with temporal data in Python, pandas provides powerful tools for handling time-based indexing through its DatetimeIndex functionality.

This tutorial will guide you through creating, manipulating, and extracting insights from pandas time indexes with practical examples.

What is a pandas DatetimeIndex?

A DatetimeIndex is a specialized index type in pandas designed specifically for time series data. Unlike regular numeric indexes, DatetimeIndex understands temporal relationships, enabling powerful time-based operations like resampling, filtering by date ranges, and extracting time components.

The DatetimeIndex serves as the backbone for time series analysis in pandas, providing a rich set of functionality that makes working with temporal data intuitive and efficient.

When you have data points that are naturally ordered by time—such as stock prices recorded every minute, temperature readings from sensors, or website traffic metrics—DatetimeIndex becomes indispensable.

import pandas as pd
import numpy as np
from datetime import datetime, timedelta

# Create a simple DatetimeIndex
dates = pd.date_range('2024-01-01', periods=10, freq='D')
print(dates)

The example above creates a DatetimeIndex with 10 consecutive days starting from January 1, 2024. The beauty of DatetimeIndex is its ability to automatically understand and handle various time-related operations that would be cumbersome with regular indexes.

Why Use DatetimeIndex?

Traditional numeric indexes treat each row as an independent entity, but time series data has inherent relationships between consecutive points. DatetimeIndex recognizes these relationships and provides specialized methods for:

Temporal filtering: Easily select data from specific periods
Resampling: Convert data from one frequency to another (e.g., daily to monthly)
Time-based grouping: Group data by time periods automatically
Missing data handling: Identify and handle gaps in time series
Time zone management: Handle data across different time zones seamlessly

Setting up your environment

Before diving into examples, ensure you have the necessary libraries installed. While pandas comes with robust datetime functionality out of the box, you’ll want additional libraries for comprehensive time series analysis:

import pandas as pd
import numpy as np
from datetime import datetime, timedelta
import matplotlib.pyplot as plt

For production environments dealing with large-scale time series data, consider installing additional packages:

pip install pandas numpy matplotlib pytz

The pytz library is particularly useful for time-zone-aware operations, while matplotlib helps visualize time series patterns. If you’re working with financial data, pandas-datareader can fetch real-time market data with proper DatetimeIndex formatting.

Creating a DatetimeIndex

Creating a DatetimeIndex is the first step in time series analysis. Pandas offers multiple approaches depending on your data source and requirements.

Method 1: Using pd.date_range()

The most common and flexible way to create a DatetimeIndex is using pd.date_range(). This method is particularly useful when you need to generate regular time intervals:

# Daily frequency for 30 days
daily_index = pd.date_range('2024-01-01', periods=30, freq='D')

# Hourly frequency for 24 hours
hourly_index = pd.date_range('2024-01-01', periods=24, freq='H')

# Monthly frequency for 12 months
monthly_index = pd.date_range('2024-01-01', periods=12, freq='M')

# Business days only (excludes weekends)
business_index = pd.date_range('2024-01-01', periods=20, freq='B')

# Custom frequency - every 15 minutes
custom_index = pd.date_range('2024-01-01 09:00', periods=32, freq='15T')

The frequency parameter (freq) accepts various aliases: ‘D’ for daily, ‘H’ for hourly, ‘T’ or ‘min’ for minutes, ‘S’ for seconds, ‘B’ for business days, ‘W’ for weekly, ‘M’ for month-end, ‘MS’ for month-start, ‘Q’ for quarter-end, and ‘A’ for year-end.

Method 2: Converting Existing Columns

In real-world scenarios, you’ll often work with datasets that have date information stored as strings or other formats. Converting these to DatetimeIndex is crucial for time series analysis:

# Sample data with date strings
data = {
   'date': ['2024-01-01', '2024-01-02', '2024-01-03', '2024-01-04'],
   'value': [100, 105, 98, 110],
   'category': ['A', 'B', 'A', 'B']
}
df = pd.DataFrame(data)

# Convert date column to datetime and set as index
df['date'] = pd.to_datetime(df['date'])
df.set_index('date', inplace=True)
print(df.index)

# Alternative: Convert and set index in one step
df = pd.DataFrame(data)
df = df.set_index(pd.to_datetime(df['date']))
df.drop('date', axis=1, inplace=True)

When dealing with non-standard date formats, pd.to_datetime() offers additional parameters:

# Handle different date formats
dates_various = ['01/15/2024', '2024-02-16', '17-Mar-2024']
df_various = pd.DataFrame({'dates': dates_various, 'values': [1, 2, 3]})

# Let pandas infer the format
df_various['dates'] = pd.to_datetime(df_various['dates'], infer_datetime_format=True)

# Or specify the format explicitly for better performance
dates_specific = ['01/15/2024', '01/16/2024', '01/17/2024']
df_specific = pd.DataFrame({'dates': dates_specific, 'values': [1, 2, 3]})
df_specific['dates'] = pd.to_datetime(df_specific['dates'], format='%m/%d/%Y')

Method 3: Direct DatetimeIndex Creation

For maximum control over the DatetimeIndex creation process, you can instantiate it directly:

# Create from a list of datetime objects
dates = [datetime(2024, 1, 1), datetime(2024, 1, 2), datetime(2024, 1, 3)]
dt_index = pd.DatetimeIndex(dates)

# Create from strings
string_dates = ['2024-01-01', '2024-01-02', '2024-01-03']
dt_index = pd.DatetimeIndex(string_dates)

# Create with timezone information
tz_dates = pd.DatetimeIndex(['2024-01-01', '2024-01-02'], tz='UTC')

# Create with specific name
named_index = pd.DatetimeIndex(string_dates, name='timestamp')

DatetimeIndex syntax and usage

The DatetimeIndex constructor provides extensive customization options for handling various time series scenarios:

pd.DatetimeIndex(
   data=None,          # Array-like of datetime objects
   freq=None,          # Frequency string
   tz=None,            # Timezone
   normalize=False,    # Normalize to midnight
   closed=None,        # Whether interval is closed
   ambiguous='raise',  # How to handle ambiguous times
   dayfirst=False,     # Interpret first value as day
   yearfirst=False,    # Interpret first value as year
   dtype=None,         # Data type
   copy=False,         # Copy input data
   name=None           # Name for the index
)

Understanding these parameters is crucial for handling edge cases in time series data:

freq: Specifies the frequency of the time series. Common values include 'D' (daily), 'H' (hourly), 'T' (minutely)
tz: Time zone information, essential for global applications
normalize: When True, normalizes times to midnight, useful for daily aggregations
ambiguous: Handles ambiguous times during daylight saving transitions
dayfirst/yearfirst: Controls date parsing when format is ambiguous

# Example with various parameters
complex_index = pd.DatetimeIndex(
   ['2024-01-01 14:30', '2024-01-02 14:30', '2024-01-03 14:30'],
   tz='America/New_York',
   freq='D',
   name='trading_times'
)

Key attributes of pandas DatetimeIndex

DatetimeIndex provides numerous attributes for accessing time components, making it easy to extract meaningful information from temporal data:

# Create sample data
dates = pd.date_range('2024-01-01', periods=100, freq='D')
df = pd.DataFrame({'value': np.random.randn(100)}, index=dates)

# Access various time components
print("Year:", df.index.year.unique())
print("Month:", df.index.month.unique())
print("Day:", df.index.day[:5])
print("Day of week:", df.index.dayofweek[:5])
print("Day name:", df.index.day_name()[:5])
print("Quarter:", df.index.quarter.unique())

The comprehensive list of available attributes includes:

Temporal components: year, month, day, hour, minute, second, microsecond
Week-related: week, dayofweek, dayofyear, weekday
Period indicators: quarter, is_month_start, is_month_end, is_quarter_start, is_quarter_end
Special properties: is_leap_year, days_in_month, freqstr

These attributes enable sophisticated time-based analysis without complex date manipulation:

# Advanced attribute usage
df['is_weekend'] = df.index.dayofweek.isin([5, 6])
df['is_month_end'] = df.index.is_month_end
df['days_in_month'] = df.index.days_in_month
df['week_number'] = df.index.isocalendar().week

# Analyze patterns
weekend_mean = df[df['is_weekend']]['value'].mean()
weekday_mean = df[~df['is_weekend']]['value'].mean()
print(f"Weekend vs Weekday difference: {weekend_mean - weekday_mean:.3f}")

Extracting time components

Extract Year from DatetimeIndex

# Create sample time series data
dates = pd.date_range('2020-01-01', '2024-12-31', freq='M')
df = pd.DataFrame({'sales': np.random.randint(1000, 5000, len(dates))}, index=dates)

# Extract year
df['year'] = df.index.year
yearly_sales = df.groupby('year')['sales'].sum()
print(yearly_sales)

Extract Month from DatetimeIndex

# Extract month number and name
df['month_num'] = df.index.month
df['month_name'] = df.index.month_name()

# Analyze monthly patterns
monthly_avg = df.groupby('month_name')['sales'].mean()
print(monthly_avg.sort_values(ascending=False))

Extract Day, Hour, and Minute Components

# Create hourly data
hourly_dates = pd.date_range('2024-01-01', periods=168, freq='H')  # One week
df_hourly = pd.DataFrame({'temperature': np.random.normal(20, 5, len(hourly_dates))},
                       index=hourly_dates)

# Extract time components
df_hourly['day'] = df_hourly.index.day
df_hourly['hour'] = df_hourly.index.hour
df_hourly['minute'] = df_hourly.index.minute

# Find peak temperature hours
hourly_avg = df_hourly.groupby('hour')['temperature'].mean()
print(f"Peak temperature hour: {hourly_avg.idxmax()}")

Advanced DatetimeIndex operations

Find First and Last Day of Month

# Check if date is first day of month
df['is_month_start'] = df.index.is_month_start

# Check if date is last day of month
df['is_month_end'] = df.index.is_month_end

# Filter for month-end data
month_end_data = df[df['is_month_end']]
print(month_end_data.head())

Find Start and End of Year

# Check if date is first day of year
df['is_year_start'] = df.index.is_year_start

# Check if date is last day of year
df['is_year_end'] = df.index.is_year_end

# Get year-end values
year_end_sales = df[df['is_year_end']]['sales']
print(year_end_sales)

Identify Leap Years

# Check if year is leap year
df['is_leap_year'] = df.index.is_leap_year

# Count leap year occurrences
leap_year_count = df['is_leap_year'].sum()
print(f"Number of leap year entries: {leap_year_count}")

Working with Day of Week

# Get day of week (0=Monday, 6=Sunday)
df['day_of_week'] = df.index.dayofweek
df['day_name'] = df.index.day_name()

# Analyze weekday vs weekend patterns
df['is_weekend'] = df['day_of_week'].isin([5, 6])
weekend_avg = df[df['is_weekend']]['sales'].mean()
weekday_avg = df[~df['is_weekend']]['sales'].mean()

print(f"Weekend average: {weekend_avg:.2f}")
print(f"Weekday average: {weekday_avg:.2f}")

Rounding Dates in DatetimeIndex

DatetimeIndex supports rounding operations for aggregating data:

# Create minute-level data
minute_dates = pd.date_range('2024-01-01 09:00', periods=120, freq='T')
df_minutes = pd.DataFrame({'price': np.random.normal(100, 2, len(minute_dates))},
                        index=minute_dates)

# Round to different frequencies
df_minutes['hour_rounded'] = df_minutes.index.round('H')
df_minutes['15min_rounded'] = df_minutes.index.round('15T')

# Aggregate by rounded time
hourly_avg = df_minutes.groupby('hour_rounded')['price'].mean()
print(hourly_avg)

Time Series Filtering and Slicing

DatetimeIndex enables intuitive time-based filtering:

# Create sample data
dates = pd.date_range('2024-01-01', '2024-12-31', freq='D')
df = pd.DataFrame({'value': np.random.randn(len(dates))}, index=dates)

# Filter by year
data_2024 = df['2024']

# Filter by month
january_data = df['2024-01']

# Filter by date range
q1_data = df['2024-01':'2024-03']

# Filter using boolean indexing
recent_data = df[df.index >= '2024-06-01']

Resampling with DatetimeIndex

One of the most powerful features is resampling:

# Daily data resampled to weekly
weekly_data = df.resample('W').mean()

# Daily data resampled to monthly
monthly_data = df.resample('M').agg({
   'value': ['mean', 'std', 'min', 'max']
})

print(monthly_data.head())

Working with Time Zones

DatetimeIndex supports time-zone-aware operations:

# Create timezone-aware index
utc_dates = pd.date_range('2024-01-01', periods=10, freq='D', tz='UTC')
df_tz = pd.DataFrame({'value': range(10)}, index=utc_dates)

# Convert to different timezone
df_tz_ny = df_tz.tz_convert('America/New_York')
print(df_tz_ny.index)

Integration with InfluxDB

When working with time series databases like InfluxDB, DatetimeIndex becomes even more valuable for data preparation and analysis. InfluxDB 3.0’s Python client integrates seamlessly with Pandas DataFrames that use DatetimeIndex:

# Example of preparing data for InfluxDB
def prepare_for_influxdb(df):
   """Prepare DataFrame with DatetimeIndex for InfluxDB insertion"""
   # Ensure index is timezone-aware
   if df.index.tz is None:
       df.index = df.index.tz_localize('UTC')

   # Add timestamp column for InfluxDB
   df['timestamp'] = df.index

   return df

# Usage example with sensor data
sensor_dates = pd.date_range('2024-01-01', periods=1000, freq='5T')
sensor_df = pd.DataFrame({
   'temperature': np.random.normal(22, 3, 1000),
   'humidity': np.random.normal(45, 10, 1000),
   'sensor_id': 'sensor_001'
}, index=sensor_dates)

prepared_df = prepare_for_influxdb(sensor_df)

# The prepared DataFrame can now be written to InfluxDB
# with proper timestamp handling and timezone awareness

InfluxDB’s strength in handling high-cardinality time series data complements pandas’ analytical capabilities. You can query data from InfluxDB, perform complex analysis using DatetimeIndex operations, and write results back to the database:

# Example workflow with InfluxDB integration
def analyze_sensor_data(df):
   """Analyze sensor data using DatetimeIndex features"""
   # Resample to hourly averages
   hourly_avg = df.resample('H').mean()

   # Identify daily patterns
   hourly_avg['hour'] = hourly_avg.index.hour
   daily_pattern = hourly_avg.groupby('hour')[['temperature', 'humidity']].mean()

   # Find anomalies (values beyond 2 standard deviations)
   temp_std = df['temperature'].std()
   temp_mean = df['temperature'].mean()
   df['temp_anomaly'] = abs(df['temperature'] - temp_mean) > 2 * temp_std

   return hourly_avg, daily_pattern, df

# This analysis leverages DatetimeIndex for efficient time-based operations
# that would be complex with traditional indexing approaches

Best practices and performance tips

Effective use of DatetimeIndex requires understanding performance implications and following established best practices.

1. Choosing Appropriate Frequency

Select the right frequency for your data to optimize memory usage and query performance:

# For high-frequency data, consider the trade-off between granularity and performance
# Minute-level data for a year: 525,600 rows
minute_data = pd.date_range('2024-01-01', '2024-12-31 23:59', freq='T')

# Daily data for a year: 366 rows (much more manageable)
daily_data = pd.date_range('2024-01-01', '2024-12-31', freq='D')

# Choose based on your analysis needs

2. Time Zone Awareness

Always be explicit about time zones in production systems to avoid confusion and errors:

# Good: Explicit timezone
utc_index = pd.date_range('2024-01-01', periods=100, freq='D', tz='UTC')

# Better: Convert to local timezone when needed
local_index = utc_index.tz_convert('America/New_York')

# Best: Document timezone assumptions in your code
def create_trading_hours_index(start_date, periods):
   """Create DatetimeIndex for US trading hours (9:30 AM - 4:00 PM ET)"""
   return pd.date_range(
       start=start_date + ' 09:30:00',
       periods=periods,
       freq='B',  # Business days only
       tz='America/New_York'
   )

3. Efficient Filtering

Use string-based indexing for date ranges when possible, as it’s more readable and often faster:

# Efficient: String-based filtering
q1_data = df['2024-01':'2024-03']
january_data = df['2024-01']

# Less efficient: Boolean indexing for simple date ranges
q1_data_bool = df[(df.index "= '2024-01-01') & (df.index "= '2024-03-31')]

4. Memory Optimization

Consider using categorical data types for repeated time components:

# Memory-efficient approach for repeated analysis
df['month_name'] = df.index.month_name().astype('category')
df['day_name'] = df.index.day_name().astype('category')

# This reduces memory usage when you have many repeated values

5. Vectorized Operations

Leverage vectorized operations instead of loops for better performance:

# Efficient: Vectorized operations
df['is_business_day'] = df.index.dayofweek " 5
df['quarter_start'] = df.index.is_quarter_start

# Inefficient: Loop-based approach
# for i, date in enumerate(df.index):
#     df.loc[date, 'is_business_day'] = date.dayofweek " 5

Common pitfalls and solutions

Understanding common challenges with DatetimeIndex helps avoid frustrating debugging sessions and ensures robust time series analysis.

Handling Missing Dates

Time series data often has gaps due to system downtime, weekends, holidays, or irregular data collection. DatetimeIndex provides elegant solutions:

# Create data with missing dates
irregular_dates = ['2024-01-01', '2024-01-03', '2024-01-05']
df_irregular = pd.DataFrame({'value': [1, 2, 3]},
                          index=pd.to_datetime(irregular_dates))

# Reindex to fill missing dates
full_range = pd.date_range('2024-01-01', '2024-01-05', freq='D')
df_complete = df_irregular.reindex(full_range)
print(df_complete)

# Fill missing values with different strategies
df_forward_fill = df_complete.fillna(method='ffill')  # Forward fill
df_interpolated = df_complete.interpolate()  # Linear interpolation
df_zero_fill = df_complete.fillna(0)  # Fill with zeros

Dealing with Different Date Formats

Real-world data often comes in various date formats. Robust parsing is essential:

# Mixed date formats
mixed_dates = ['01/15/2024', '2024-01-16', '17-Jan-2024']
standardized = pd.to_datetime(mixed_dates, infer_datetime_format=True)
print(standardized)

# Handle parsing errors gracefully
problematic_dates = ['01/15/2024', 'invalid_date', '2024-01-17']
safe_dates = pd.to_datetime(problematic_dates, errors='coerce')
print(safe_dates)  # Invalid dates become NaT (Not a Time)

# Custom parsing for specific formats
custom_format_dates = ['15-Jan-2024 14:30', '16-Jan-2024 15:45']
parsed_custom = pd.to_datetime(custom_format_dates, format='%d-%b-%Y %H:%M')

Time Zone Conversion Issues

Time zone handling can be tricky, especially with daylight saving time transitions:

# Create timezone-naive data
naive_dates = pd.date_range('2024-03-10', periods=5, freq='D')
df_naive = pd.DataFrame({'value': range(5)}, index=naive_dates)

# Localize to a specific timezone
df_localized = df_naive.tz_localize('US/Eastern')

# Handle ambiguous times during DST transitions
dst_dates = pd.date_range('2024-11-03 01:00', periods=4, freq='H', tz='US/Eastern')
# This might raise an error due to ambiguous times

# Solution: Handle ambiguous times explicitly
safe_dst = pd.date_range('2024-11-03 01:00', periods=4, freq='H',
                       tz='US/Eastern', ambiguous='infer')

Performance Issues with Large Datasets

Large time series datasets require careful memory and performance management:

# For very large datasets, consider chunking
def process_large_timeseries(file_path, chunk_size=10000):
   """Process large time series data in chunks"""
   results = []

   for chunk in pd.read_csv(file_path, chunksize=chunk_size,
                           parse_dates=['timestamp'], index_col='timestamp'):
       # Process each chunk
       processed_chunk = chunk.resample('H').mean()
       results.append(processed_chunk)

   return pd.concat(results)

# Use efficient data types
def optimize_dtypes(df):
   """Optimize DataFrame data types for memory efficiency"""
   for col in df.select_dtypes(include=['float64']).columns:
       df[col] = df[col].astype('float32')

   for col in df.select_dtypes(include=['int64']).columns:
       df[col] = df[col].astype('int32')

   return df

Overview

Pandas DatetimeIndex is an essential tool for time series analysis, providing intuitive methods for handling temporal data.

From basic operations like extracting time components to advanced features like resampling and time zone handling, DatetimeIndex enables efficient time-based data manipulation that would be cumbersome or impossible with traditional indexing approaches.

The power of DatetimeIndex lies not just in its individual features, but in how they work together to create a comprehensive time series analysis ecosystem.

Whether you’re analyzing financial market data to identify trading patterns, processing IoT sensor readings to detect anomalies, or examining web analytics to understand user behavior trends, DatetimeIndex provides a foundation for sophisticated temporal analysis.

As time series data continues to grow in volume and importance across industries, mastering DatetimeIndex becomes increasingly valuable. The techniques covered in this tutorial provide a solid foundation, but the real learning comes from applying these concepts to your specific use cases.

For large-scale time series applications, consider pairing pandas with specialized time series databases like InfluxDB to handle high-volume, high-velocity temporal data efficiently. InfluxDB’s optimized storage and query engine, combined with pandas’ analytical capabilities, creates a powerful platform for time series analysis at any scale.

The examples in this tutorial provide a comprehensive starting point for working with time-indexed data in pandas.

Practice these techniques with your own datasets, experiment with different frequency settings, and explore the extensive documentation to become proficient in time series analysis with Python.

Remember that effective time series analysis is as much about understanding your data’s temporal patterns as it is about mastering the technical tools to analyze them.

Exponential Smoothing: A Guide to Getting Started

Community (InfluxData) — Tue, 03 Feb 2026 08:00:00 +0000

Exponential smoothing is a time series forecasting method that uses an exponentially weighted average of past observations to predict future values. In other words, it assigns greater weight to recent observations than to older ones, allowing the forecast to adapt to changing data trends.

In this post, we’ll look at the basics of exponential smoothing, including how it works, its types, and how to implement it in Python.

What is exponential smoothing?

Exponential smoothing forecasts time series data by smoothing out fluctuations in the data. The technique was first introduced by Robert Goodell Brown in 1956 and then further developed by Charles Holt in 1957. It has since become one of the most widely used methods for forecasting.

The basic idea behind exponential smoothing is to give more weight to recent observations by assigning weights to each observation that decrease exponentially with age. Weights are then used to calculate a weighted moving average of the data, which is used to forecast the next period.

Exponential smoothing assumes that future values of a time series are a function of its past values. The method works well when the time series has a trend and/or a seasonal component, but it can also be used for stationary data (i.e., without trend or seasonality).

Types of exponential smoothing

There are several types of exponential smoothing methods, each with its own formulae and assumptions. The most commonly used methods include:

1. Simple Exponential Smoothing

Simple exponential smoothing (SES), also known as single exponential smoothing, is its simplest form. It assumes that the time series has no trend or seasonality.

The forecast for the next period is based on the weighted average of the previous observation and the forecast for the current period.

The formula for simple exponential smoothing is:

s_(t) = αx_(t) + (1-α)s_t-1

where

s_(t) is the smoothed value at time t,
x_(t) is the observed value at time t,
s_t-1 is the previous smoothed statistic, and
α is the smoothing parameter between 0 and 1.

The smoothing parameter α controls the weight given to the current observation and the previous forecast.

A high value of α gives more weight to the current observation, while a low value of α gives more weight to the previous forecast.

2. Holt’s Linear Exponential Smoothing

Holt’s linear exponential smoothing, also known as double exponential smoothing, is used to forecast time series data that has a linear trend but no seasonal pattern. This method uses two smoothing parameters: α for the level (the intercept) and β for the trend.

The formulas for double exponential smoothing are:

s_t = αx_t + (1 – α)(s_t-1 + b_t-1)

β_t = β(s_t – s_t-1) + (1 – β)b_t-1

where

bt is the slope and best estimate of the trend at time t,
α is the smoothing parameter of data (0 < α < 1), and
β is the smoothing parameter for the trend (0 < β < 1).

Holt’s method is more accurate than SES for time series data with a trend, but it doesn’t work well for time series data with a seasonal component.

3. Holt-Winters’ Exponential Smoothing

Holt-Winters’ exponential smoothing, also referred to as triple exponential smoothing, is used to forecast time series data with both a trend and a seasonal component. It uses three smoothing parameters: α for the level (the intercept), β for the trend, and γ for the seasonal component.

The triple exponential smoothing formulas are given by:

where:

s_t = smoothed statistic; it’s the simple weighted average of current observation Y_t
s_t-1 = previous smoothed statistic
α = smoothing factor of data (0 < α < 1)
t = time period
b_t = best estimate of a trend at time t
β = trend smoothing factor (0 < β <1)
c_t = seasonal component at time t
γ = seasonal smoothing parameter (0 < γ < 1)

Holt-Winters’ method is the most accurate of the three methods, but it’s also the most complex, requiring more data and computation than the other methods.

When to use exponential smoothing

Exponential smoothing is most useful for time series data that has a consistent trend, seasonality, and random fluctuations.

It’s particularly useful for short to medium-term forecasting of business metrics such as sales, revenue, and customer traffic. It’s also useful for monitoring and predicting seasonal changes in industries such as tourism, agriculture, and energy.

Here are some other common situations where exponential smoothing can be useful:

Time series forecasting — One of the most common applications of exponential smoothing is in time series forecasting. If you have historical data for a particular variable over time, such as sales or website traffic, you can use exponential smoothing to forecast the future values of that variable.
Inventory management — Exponential smoothing can be used to forecast demand for products or services, which can be helpful in inventory management. By forecasting demand, businesses can make sure they have enough inventory on hand to meet customer needs without overstocking.
Finance — It can be used in finance to forecast stock prices, interest rates, and other financial variables. This can be helpful for investors who are trying to make informed decisions about buying and selling stocks or other financial instruments.
Marketing — It’s also used to forecast the effectiveness of marketing campaigns. By tracking past campaign results and using exponential smoothing to forecast future performance, marketers can optimize their campaigns to achieve the best possible results.

Why is exponential smoothing popular?

Exponential smoothing is among the most widely used time series forecasting methods due to its simplicity and effectiveness.

Unlike other methods, exponential smoothing can adapt to changes in data trends. It also provides accurate predictions by assigning different weights to different time periods based on their importance.

Exponential smoothing is computationally efficient, making it ideal for large datasets. Additionally, it’s widely used in business forecasting, providing accurate, reliable forecasts across a range of applications, including demand, sales, and financial forecasting.

How to perform exponential smoothing

Performing exponential smoothing begins with understanding your data’s structure.

First, examine your time series to identify whether it contains trends, seasonality, or neither. This analysis will guide you in selecting the right exponential smoothing method: SES works best for stationary data, Holt’s method handles data with trends, and Holt-Winters’ method addresses both trends and seasonal patterns.

Once you’ve chosen your method, the implementation is straightforward. Modern statistical software and libraries can automatically optimize the smoothing parameters (α, β, and γ) by finding values that minimize forecast errors.

After fitting the model to your historical data, you’ll have a trained forecasting tool ready to generate predictions for future time periods.

Now, let’s put this into practice by implementing exponential smoothing using Python, one of the most popular tools for time series analysis.

Exponential smoothing in Python

Python has several libraries for exponential smoothing, including Pandas, Statsmodels, and Prophet. These libraries provide various functions and methods for implementing different types of exponential smoothing methods.

The Dataset

For this example, we’ll use the AirPassengers dataset, a time series dataset that contains the monthly number of airline passengers from 1949 to 1960. You can download the dataset from this link.

Setting Up the Environment

To get started, we need to set up our environment. We’ll be using Python 3, so make sure it’s installed. Alternatively, you can use Google Colab and go straight to importing the libraries.

Next, install these libraries using pip:

pip install pandas matplotlib statsmodels

Once you’ve installed the necessary libraries, you can import them into your Python script:

import pandas as pd
import matplotlib.pyplot as plt
from statsmodels.tsa.api import SimpleExpSmoothing

Loading the Data

After setting up the environment, we can load the AirPassengers dataset into a pandas DataFrame using the read_csv function:

data = pd.read_csv('airline-passengers.csv', parse_dates=['Month'], index_col='Month')

We can then inspect the first few rows of the DataFrame using the head function:

print(data.head())

This will output:

Visualizing the Data

Before we apply simple exponential smoothing to the data, let’s visualize it to get a better understanding of its properties. We can use the plot function of pandas to create a line plot of the data:

plt.plot(data)
plt.xlabel('Year')
plt.ylabel('Number of Passengers')
plt.show()

This will produce a plot of the number of passengers over time:

We can see that the number of passengers appears to be increasing, with some seasonality as well.

Performing SES

Now that we’ve loaded and visualized the data, we can perform simple exponential smoothing using the SimpleExpSmoothing function from the statsmodels library. Then, we’ll create an instance of the SimpleExpSmoothing class, passing in the data as an argument, and then fit the model to the data using the fit method:

model = SimpleExpSmoothing(data)
model_fit = model.fit(optimized=True)
print(model_fit.summary())

This will calculate the smoothing parameters and fit the model to the data. The optimized=True parameter allows the model to find the best smoothing parameter (α) for your data.

Making Predictions

Finally, we can use the forecast method to predict future values of the time series, where the argument specifies the number of periods to forecast.

forecast = model_fit.forecast(6)
print(forecast)

This will produce a forecast for the next six months:

Based on the forecast, we can assume that over the next six months, there will be approximately 432 airline passengers.

Wrapping up

Exponential smoothing is a powerful method for time series forecasting that allows for accurate predictions of future values based on past observations. It’s a simple, efficient method that can be used for a wide range of time series data.

In this post, we provided a beginner’s guide to exponential smoothing, explaining the basics of the method, its types, and how to use it for forecasting. However, there are more advanced techniques and approaches to discover beyond the scope of this post.

If you’re interested in learning more, be sure to check out this Python time series forecasting tutorial. It’s a great resource that can help you deepen your understanding of this topic and take your forecasting skills to the next level with InfluxDB.

Exponential smoothing FAQs

What is the smoothing parameter α in exponential smoothing and how do I choose it?

The smoothing parameter α (alpha) controls how much weight is given to the most recent observation versus older data. A value close to 1 makes the forecast highly responsive to the latest data point, while a value close to 0 places more emphasis on the historical average. In practice, you don't need to set α manually — libraries like Python's statsmodels can automatically optimize α by minimizing forecast error when you use the optimized=True parameter.

What is the difference between simple, double, and triple exponential smoothing?

Simple exponential smoothing (SES) works best for stationary data with no trend or seasonality, using a single smoothing parameter α. Double exponential smoothing (Holt's method) adds a second parameter β to handle data with a linear trend. Triple exponential smoothing (Holt-Winters' method) adds a third parameter γ to also capture seasonal patterns, making it the most accurate of the three but also the most computationally demanding.

How do I know which exponential smoothing method to use for my data?

Start by plotting your time series and examining its structure. If the data is relatively flat with no clear upward/downward drift or repeating seasonal cycles, use Simple Exponential Smoothing. If there's a consistent trend but no seasonality, use Holt's linear method. If both a trend and seasonal pattern are visible — such as sales data that peaks every holiday quarter — use Holt-Winters' method. The key is to visually inspect your data before selecting a model.

Is exponential smoothing the same as a moving average?

They are related but not the same. A simple moving average gives equal weight to all observations in the window and completely ignores data outside it. Exponential smoothing, on the other hand, uses all historical data but assigns weights that decrease exponentially with age — meaning the most recent observations have the greatest influence. This makes exponential smoothing more adaptive to recent changes than a standard moving average.

What Python libraries can I use for exponential smoothing?

The most commonly used library is statsmodels, which provides SimpleExpSmoothing for SES and ExponentialSmoothing for Holt's and Holt-Winters' methods. You'll also typically use pandas for loading and preparing your time series data and matplotlib for visualizing it. All three can be installed via pip and work well together for end-to-end forecasting workflows in Python.

What are the limitations of exponential smoothing?

Exponential smoothing is best suited for short to medium-term forecasting and assumes that future patterns will resemble past ones. It struggles with abrupt structural changes in the data, such as sudden market shifts or one-time events, because the model adapts gradually. It also doesn't capture complex non-linear relationships between multiple variables. For longer-horizon forecasts or multivariate scenarios, models like ARIMA, SARIMA, or machine learning-based approaches may be more appropriate.

How accurate are exponential smoothing forecasts?

Forecast accuracy depends on how well the chosen method matches your data's structure. When the right variant is applied — SES for stationary data, Holt's for trended data, Holt-Winters' for seasonal data — exponential smoothing consistently delivers strong results for short to medium-term horizons. Accuracy also improves when smoothing parameters are automatically optimized to minimize error on your historical data, as supported by statsmodels' optimized=True option.

This post was written by Israel Oyetunji. Israel is a frontend developer with a knack for creating engaging UI and interactive experiences. He has proven experience developing consumer-focused websites using HTML, CSS, JavaScript, ReactJS, SASS, and relevant technologies. He loves writing about tech and creating how-to tutorials for developers.

Building with the InfluxDB 3 MCP Server & Claude

Suyash Joshi (InfluxData) — Fri, 30 Jan 2026 08:00:00 +0000

InfluxDB 3 Model Context Protocol (MCP) server lets you manage and query InfluxDB 3 (Core, Enterprise, Dedicated, Serverless, Clustered) using natural language through popular LLM tools like Claude Desktop, ChatGPT Desktop, and other MCP-compatible agents.

The setup is straightforward. In this article, we will focus on setting up InfluxDB 3 Enterprise using Docker with Claude Desktop.

Prerequisites

Install InfluxDB 3 Enterprise using Docker (if you’re a new user, try out our free trial) on your machine by running the installer script:

curl -O https://www.influxdata.com/d/install_influxdb3.sh && sh install_influxdb3.sh enterprise

InfluxDB 3 Explorer UI will also make it easier to manage InfluxDB operations, so it’s recommended that you install it (using Docker) during initial setup or afterwards.

1. Create an InfluxDB 3 token for MCP server

The easiest way to create a scoped token is within InfluxDB 3 Explorer UI.

Open Explorer at http://localhost:8888.
Go to Manage Tokens.
Create a Database (resource) token with read (and optional write) permissions for the databases you want your LLM to access.
Copy the token string and store it securely; the MCP server will use it as INFLUX_DB_TOKEN.

Alternatively, you can run the following command inside a Docker container to create the token.

docker exec -it YOUR_CONTAINER_ID influxdb3 create token \
  --permission "db:DATABASE1,DATABASE2:read,write" \
  --name "Read-write on DATABASE1, DATABASE2" \
  --token YOUR_ADMIN_TOKEN \
  --expiry 1y

Security Tip: Use resource tokens with the minimum required permissions and an expiration date, rather than providing a full admin token to the LLM MCP.

2. Configure the Claude Desktop MCP server (Docker) for InfluxDB 3 Enterprise

The InfluxDB 3 MCP server runs as a separate service and can be started using either Node.js or Docker. We will use Docker, as it’s already running InfluxDB 3 and Explorer UI.

Open Claude Desktop.
Navigate to Settings → Developers → Edit Config
Open the Claude Desktop configuration file, add the following to the existing file, save, and restart Claude Desktop.

{
  "mcpServers": {
    "influxdb": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "--interactive",
        "--add-host=host.docker.internal:host-gateway",
        "--env",
        "INFLUX_DB_PRODUCT_TYPE",
        "--env",
        "INFLUX_DB_INSTANCE_URL",
        "--env",
        "INFLUX_DB_TOKEN",
        "influxdata/influxdb3-mcp-server"
      ],
      "env": {
        "INFLUX_DB_PRODUCT_TYPE": "enterprise",
        "INFLUX_DB_INSTANCE_URL": "http://host.docker.internal:8181",
        "INFLUX_DB_TOKEN": "YOUR_RESOURCE_TOKEN"
      }
    }
  }
}

3. Use Claude with InfluxDB via MCP

Once restarted, verify that Claude can access the InfluxDB 3 MCP server by chatting with it.

Finally, you can interact with the database however you’d like, such as performing operations, getting analytics, etc., using natural language. Try the following prompts:

“List all the databases and permissions you have access to.”
“Show me the schema for the sensor_data table.”
“Analyze bitcoin sample data price in the last 30 days.” You can also see the actual SQL query that gets executed.

Connecting other LLMs

In this article we used Claude Desktop, but the InfluxDB 3 MCP server itself is generic. Any LLM agent that supports the Model Context Protocol can be used. For example, ChatGPT Desktop. In a follow-up article, we’ll cover how to run the MCP server and an LLM locally using other tools. We would love to hear your comments/questions, etc., on our community website, Slack, or Discord.

Getting Started with InfluxDB and Pandas: A Beginner's Guide

Community (InfluxData) — Tue, 27 Jan 2026 08:00:00 +0000

InfluxData prides itself on prioritizing developer happiness. A key ingredient to that formula is providing client libraries that let users interact with the database in their chosen language and library. Data analysis is the task most broadly associated with Python use cases, accounting for 58% of Python tasks, so it makes sense that Pandas is the second most popular library for Python users. The InfluxDB 3 Python client library supports Pandas DataFrames, making it easy for data scientists to use InfluxDB.

In this tutorial, we’ll learn how to query our InfluxDB instance and return the data as a DataFrame. We’ll also explore some data science resources included in the Client repo. To learn about how to get started with the InfluxDB 3 Python client library, please take a look at this video.

Me eagerly consuming Pandas and InfluxDB Documentation. Photo by Sid Balachandran on Unsplash.

Data science resources

A variety of data science resources have been included in the InfluxDB Python client repo to help you take advantage of the Pandas functionality of the client. I encourage you to take a look at the example notebooks.

Dependencies

pyarrow (automatically comes with influxdb3-python installation)
pandas
certifi (if you are using Windows)

Installations

pip install influxdb3-python pandas certifi

Import Dependencies


import influxdb_client_3 as influxDBclient3
import pandas as pd
Import certifi #if you are on Windows
from influxdb_client_3 import flight_client_options

Initialization

Direct Initialization

Take note that the “database” argument in the function is the bucket name if you are using InfluxDB cloud:

client = InfluxDBClient3(token="your-token",
                         host="your-host",
                         database="your-database or your bucket name")

For Windows Users

Include certifi within the “flight_client_options” argument within the client initialization to fix certificate issues:

with open(certifi.where(), "r") as fh:
    cert = fh.read()
client = InfluxDBClient3(token="your-token",
                         host="your-host",
                         database="your-database or your bucket name”,
flight_client_options=flight_client_options(tls_root_certs=cert)

Prepare a pandas Dataframe

Let’s use simple weather data:


# Example weather data
df = pd.DataFrame({
    "timestamp": pd.date_range("2025-09-01", periods=4, freq="h", tz="UTC"),
    "city": ["Lagos", "Illinois", "Chicago", "Abuja"],
    "temperature": [30.5, 15, 16, 32],
    "humidity": [20, 10, 10, 19]
})

# ensure timestamp dtype is datetime64[ns] and (optionally) timezone-aware
df['timestamp'] = pd.to_datetime(df['timestamp'], utc=True)
print(df.head())

Weather timestamp data.

Write the pandas Dataframe to InfluxDB


client._write_api.write(
    bucket="my_bucket",
    record=df,
    data_frame_measurement_name="weather",
    data_frame_tag_columns=["city", "temperature"],
    data_frame_timestamp_column="timestamp"
)
print("DataFrame written to bucket=new-test-bucket, measurement=weather")

Below is confirmation in your InfluxDB Cloud that the Pandas DataFrame was successfully written to the bucket.

Pandas Dataframe written to InfluxDB.

Query InfluxDB and return a Pandas DataFrame

query = "SELECT * FROM weather"
table = client.query(query=query, language="influxql")
result_df = table.to_pandas()

print("Loading from InfluxDB:")
print(result_df.head())

Returning a Pandas DataFrame from InfluxDB

Start building with InfluxDB and Pandas

InfluxDB makes it easy to integrate with your existing data analysis tools and frameworks, such as Pandas, to get insights from your time series data. Under the hood, you get the benefits of Apache Arrow for fast data transfers into Pandas DataFrames without any performance hits. Whether you’re building dashboards, machine learning models, or just exploring your metrics, combining InfluxDB 3 with Pandas gives you the best of both worlds in terms of performance and developer experience. As always, if you run into hurdles, please share them on our community site or Slack channel. We’d love to get your feedback and help with any problems you run into.

From Monitoring Signals to Observability Maturity

Allyson Boate (InfluxData) — Thu, 22 Jan 2026 08:00:00 +0000

Efficient monitoring delivers fast results: alerts fire within seconds, dashboards refresh continuously, and teams know the moment something changes.

Understanding arrives later. An alert may show that a value shifted, but it does not explain why it shifted, how far the impact will spread, or which components truly matter. Teams see the signal, not the system behavior behind it.

This gap defines the limit of traditional monitoring. Detection has improved, but explanation has not kept pace. As environments grow more interconnected, reporting change without context leaves teams reacting instead of understanding. Mature monitoring must explain behavior and impact, not just surface signals.

When context falls apart

Without context, change is difficult to interpret. An alert may confirm that something happened, but it rarely explains which dependencies influenced the behavior, how far the impact might spread, or which components are truly affected. Dashboards emphasize individual services or resources, while alerts trigger based on local thresholds instead of system-wide impact. Teams see the signal, but not the behavior behind it.

In most environments, the missing context lives elsewhere. Dependency information is scattered across configuration files, infrastructure tools, and service catalogs. Ownership and escalation paths live in runbooks. Historical relationships are reconstructed during incidents through manual analysis or ad hoc queries. This separation creates data silos, forcing teams to stitch together metrics, metadata, and system structure to gain a comprehensive view of what is actually happening.

The Cost of Fragmented Visibility

As environments scale, fragmentation becomes expensive. Root cause analysis slows as engineers trace upstream and downstream impact across multiple tools. Alert fatigue increases when signals cannot be evaluated against real dependencies. Mean time to resolution grows as teams spend more effort assembling context than resolving the issue. Even when an anomaly is detected quickly, understanding why it occurred and what it affects often arrives too late to prevent broader disruption.

The impact extends beyond incident response. Capacity planning becomes less reliable when demand shifts propagate through systems that teams cannot easily trace. SLO and SLA tracking lose precision when alerts lack impact awareness. Automation remains cautious or brittle because signals do not consistently reflect the true system state. What begins as a context gap turns into operational overhead, engineering toil, and inconsistent customer experience. Closing the gap between detection and understanding requires monitoring to evolve beyond reporting change and toward explaining system behavior and impact.

From signals to system understanding

When monitoring evolves beyond reporting signals, it gives teams the context needed to understand system behavior and impact. Observability maturity shifts monitoring from answering when something changed to explaining why it changed and what it affects. Signals no longer arrive as isolated data points; they are interpreted within the system that produced them.

With this context, teams can assess impact as soon as a signal appears. A latency spike is not just a breached threshold. It shows how activity in one component influences others, which dependencies are involved, and whether the change represents localized noise or broader risk. This perspective supports faster, more proportional responses and reduces unnecessary remediation.

When Signals Gain Meaning

As monitoring practices mature, investigations become more focused and efficient. Teams spend less time assembling dashboards or reconciling data across tools. Signals are evaluated alongside related components, making root cause analysis more transparent and reducing the effort required to identify contributing factors. Mean time to resolution (MTTR) improves because understanding arrives earlier in the response cycle.

Observability maturity also strengthens day-to-day operations. Historical telemetry reveals patterns that inform capacity planning, SLO and SLA management, and reliability goals. Alerting becomes more effective when signals are evaluated in context rather than isolation, helping reduce alert fatigue. Automation becomes safer to trust because actions reflect a clearer view of system state and impact.

In this model, monitoring supports confident decision-making. Teams move away from reactive firefighting and toward proactive operations, using telemetry not only to detect change, but to understand how systems behave as environments grow more interconnected.

How observability maturity becomes possible

Observability maturity depends on a platform that can ingest, store, and analyze telemetry within a unified execution environment. Metrics, events, and time series data must flow through the same data paths so teams can correlate change across systems rather than reconstructing context through downstream tooling or manual analysis.

By unifying ingestion and querying for metrics, events, and telemetry, InfluxDB 3 provides a time series–first observability platform that supports infrastructure, applications, edge deployments, and industrial systems through a single data model.

A Unified Telemetry Foundation

Modern environments generate large volumes of time-stamped data with rapidly changing dimensions. Supporting observability maturity requires handling high-cardinality time series data without degrading ingest performance or query latency.

InfluxDB 3 is built on a columnar analytics stack using Apache Arrow for in-memory execution and Parquet for durable, compressed storage. Telemetry flows through a single ingest path and is stored in a format optimized for analytical access, allowing recent signals and long-term history to be queried through the same interface. This design lets teams analyze live behavior, compare it to historical baselines, and identify trends without maintaining parallel storage systems or export pipelines.

Scale Without Fragmentation

As telemetry volume increases, many organizations separate ingestion, storage, and analysis into different systems. While this can address isolated scaling concerns, it fragments execution paths and makes correlation harder over time. Signals, metadata, and historical context drift into separate layers, increasing query complexity and slowing investigation.

InfluxDB 3 avoids fragmentation by keeping telemetry, metadata, and related observations within a single execution environment. Queries are planned and executed through a unified SQL engine built on DataFusion, allowing joins, filters, and aggregations to run across live and historical data without external synchronization or ETL. This preserves consistency as environments grow and keeps analysis close to the data.

Open Integration and Interoperability

Observability maturity builds on existing tools rather than replacing them overnight. Telemetry must move easily between collectors, visualization layers, automation systems, and analytics workflows. Open interfaces make this possible without forcing teams into proprietary paths.

InfluxDB 3 provides open APIs and a broad integration ecosystem, allowing telemetry to flow freely between systems while maintaining a shared source of truth. Data is stored in scalable object storage using columnar formats, supporting long retention and elastic growth without changing query behavior or operational workflows.

Analysis Close to the Data

As observability practices advance, analysis increasingly runs alongside ingestion and storage. Executing queries where data lives reduces latency and avoids inconsistencies introduced by exporting telemetry to downstream systems.

By executing analytics within the same Arrow-based environment that stores the data, InfluxDB 3 supports correlation, pattern analysis, and advanced workflows without adding architectural layers. Aligning ingestion, storage, and analysis in a single platform provides the technical foundation for monitoring practices to mature into observability at scale.

From monitoring signals to monitoring nirvana

Detecting change is no longer the challenge. Interpreting what that change means across an interconnected system is. As environments grow more complex, observability maturity depends on the ability to connect telemetry with context and history so teams can understand behavior, impact, and progression rather than reacting to isolated signals.

InfluxDB 3 makes this possible by bringing ingestion, storage, and analysis together in a single platform. With telemetry flowing through one execution path, teams maintain consistent context as systems scale. This reduces investigative friction, shortens time to insight, and gives teams the confidence to operate and automate in dynamic environments.

Get started

Try InfluxDB for free: Launch a fully-managed instance and see how modern monitoring works in your environment.

Explore documentation: Access guides, integrations, and examples to help you connect systems and build monitoring pipelines.

A New Way to Debug Query Performance in Cloud Dedicated

Reid Kaufmann (InfluxData) — Tue, 20 Jan 2026 08:00:00 +0000

I’d like to share a new influxctl ease-of-use feature in v2.12.0 that makes it easier to optimize important queries or debug slow ones. influxctl has had the capability to send queries and display the results in JSON or tabular formats for some time. (Note: this CLI utility is specific to Cloud Dedicated and Clustered, as are many of the specifics in this post.) In Clustered, you can monitor querier pods’ logs, and in both Dedicated and Clustered, metrics on individual queries’ performance can be found in the system tables. Both of those options offer a lot of data—enough that it can be hard to digest quickly. Additionally, associating a single execution of a query to its log entry is tedious. A new feature, the --perf-debug flag for the influxctl query command (release notes), accelerates the experimentation cycle by providing real-time feedback, allowing you to stay in the context of your shell as you tweak your query.

Sample output

The new flag, --perf-debug, will execute a query, collect and discard the results, and emit execution metrics instead. When --format is omitted, output defaults to a tabular format with units dynamically chosen for human readability. In the second execution below, --format json is specified to emit a data format appropriate for programmatic consumption: in a nod to the querier log, it uses keys with shorter variable names, delimits words with underscores, and sports consistent units (bytes, seconds as a float).

In the tabular format, you can also see a demarcation between client and server metrics.

$ influxctl query --perf-debug --token REDACTED --database reidtest3 --language influxql "SELECT SUM(i), non_negative_difference(SUM(i)) as diff_i FROM data WHERE time > '2025-11-07T01:20:00Z' AND time " '2025-11-07T03:00:00Z' AND runid = '540cd752bb6411f0a23e30894adea878' GROUP BY time(5m)"
+--------------------------+----------+
| Metric                   | Value    |
+--------------------------+----------+
| Client Duration          | 1.222 s  |
| Output Rows              | 20       |
| Output Size              | 647 B    |
+--------------------------+----------+
| Compute Duration         | 37.2 ms  |
| Execution Duration       | 243.8 ms |
| Ingester Latency Data    | 0        |
| Ingester Latency Plan    | 0        |
| Ingester Partition Count | 0        |
| Ingester Response        | 0 B      |
| Ingester Response Rows   | 0        |
| Max Memory               | 70 KiB   |
| Parquet Files            | 1        |
| Partitions               | 1        |
| Planning Duration        | 9.6 ms   |
| Queue Duration           | 286.6 µs |
+--------------------------+----------+

$ influxctl query --perf-debug --format json --token REDACTED --database reidtest3 --language influxql "SELECT SUM(i), non_negative_difference(SUM(i)) as diff_i FROM data WHERE time > '2025-11-07T01:20:00Z' AND time " '2025-11-07T03:00:00Z' AND runid = '540cd752bb6411f0a23e30894adea878' GROUP BY time(5m)"
{
  "client_duration_secs": 1.101,
  "compute_duration_secs": 0.037,
  "execution_duration_secs": 0.247,
  "ingester_latency_data": 0,
  "ingester_latency_plan": 0,
  "ingester_partition_count": 0,
  "ingester_response_bytes": 0,
  "ingester_response_rows": 0,
  "max_memory_bytes": 71744,
  "output_bytes": 647,
  "output_rows": 20,
  "parquet_files": 1,
  "partitions": 1,
  "planning_duration_secs": 0.009,
  "queue_duration_secs": 0
  }

Notes

Client duration includes the time to open the connection to the server. In the example, you can see a big delta between that and the server’s total duration. When I ran this command, my client and database server were not colocated. Additionally, influxctl may not be tuned for optimal connection latency. Your native client probably caches connections and might not suffer this latency. When tuning your query, it’s more important to look at the durations recorded by the server.

Output size is the size in Arrow format in memory, after gzip inflation (if client and server agree on compression), so this metric does not report the bytes transferred. The network bytes transferred might be more useful, so that’s a potential future enhancement. However, the current metric can still provide a relative metric to compare between different queries.

Ingester metrics are zeroed out if the ingester has no partitions with unpersisted data matching the query. In Serverless, Dedicated, and Clustered, queries always consult ingesters, so the 0 in ingester latency can be misleading.

Parquet files indicate how many files were traversed for the query. However, if the query was optimized by a ProgressiveEvalExec plan (simple sorted LIMIT queries without aggregations, typically; verify with EXPLAIN ANALYZE), this value may not be useful because it is calculated in planning and then reflects the potential number of files to be accessed determined by the time range, as opposed to the actual number accessed before reaching the LIMIT. For most queries, this metric is a handy indicator, but it’s worth noting that the query log also contains a related metric, deduplicated_parquet_files, which tells us how many of the files had overlapping time ranges, requiring the querier to merge/sort/deduplicate data. It’s normal to have a few files at the leading edge, but this operation becomes a serious bottleneck if too much data needs to be deduplicated (the main responsibility of the compactor is to manage this problem).

Query durations vary, and a query can be executed several times (and at different times of day) to get a sense of the variation.

Potential sources of latency or variability

Cache warmup (shows up in Execution Duration): The first few times a query in a particular time frame for a table is executed, the duration may be significantly higher due to parquet cache misses. Queries fan out to multiple queriers in a round robin fashion, and each querier has an independent parquet cache, so expect a few cache misses as each querier may have to incur the delay of retrieving parquet files from the object store. Due to multiple load balancer pods and other clients executing queries, how many query executions it will take to warm up all queries is indeterminate. If the queries are on the “leading” edge of the data, be aware that persistence of new data OR compaction may also periodically cause cache misses. Large L2 file compactions lead to a greater disruption, while latency from typical small incremental persists may be imperceptible.

Corollary: cache eviction. Other queries executing may cause cache eviction to make room for their data. Given a high rate of queries covering a lot of data (many series and/or a wide time frame), it’s possible to thrash the cache. In this case, influxctl can’t provide much context about other queries running at the same time (exception: a non-zero Queue Duration does indicate maximum execution concurrency was reached). You may still need to review the query log or observability dashboards. Some query loads are cyclical, and so is the work of the compactor, depending on ingest and partitioning rates; therefore, you may get better performance in the afternoon than in the morning. When the CPU is maxed out, it tends to increase all recorded server latencies.

Variation in data density or volume will affect all queries to some degree, but will impact computationally intensive queries the most. This shows up in Execution Duration. Monitor the Parquet Files or the Output Rows metrics as possible proxies for this. Be aware that changing a tag value in the WHERE clause or the time constraints may affect latency, depending on the underlying data. Not all writers may employ the same frequency. When tuning aggregate queries, you may occasionally want to add a COUNT() field and drop the --perf-debug flag to see how many records are contributing. For some queries (SELECT DISTINCT, for example), tag cardinality and time range can greatly impact performance.

See documentation for more general information on query optimization.

Other things to try

Check if Planning Duration is substantially higher than Execution Duration. This can be caused by high numbers of tables or partitions, which may be excessive or intended. Custom partitioning can help reduce execution latency, but can increase planning latency—find the right balance for your workload.
Check if Ingester Latency or Response is abnormally high/large. It may indicate a need for, or a problem with, custom partitioning, resulting in excessive delay in persisting partitions.
If Parquet Files is abnormally large, check that the query has a time constraint and that it’s reasonable. Also, check observability dashboards to see if the compactor is not keeping up or look for skipped partitions. If customer partitioning on a tag is in use, make sure the query is specifying a value for that tag in the WHERE clause (also note that regexes that don’t equate to simple equality checks on said field will also prevent partition pruning).
How much does increasing or decreasing the time range of the query change the execution metrics?
Compare similar queries against different tables, schemas, or partitioning schemes.
Compare different means of achieving the same result (SQL ORDER BY time DESC LIMIT 1 vs INFLUXQL LAST)

You can learn a lot through experimentation and finding correlations beyond those suggested here. We hope this minor feature makes it a little easier!

InfluxData Blog

What’s New in InfluxDB 3.9: More Operational Control and a New Performance Preview

Operational maturity and system transparency

Now in beta: A new performance preview

Get started and share your feedback:

What is MRO? Maintenance, Repair, and Operations Explained

What is MRO?

Common MRO Supplies and Activities

Why MRO matters

Maintenance strategies: preventive, predictive, planned, and condition-based

Preventive Maintenance

Planned Maintenance

Condition-Based Maintenance

Predictive Maintenance

MRO in manufacturing

MRO in aviation

MRO in energy and utilities

MRO procurement, inventory, and software

Inventory

Software

Where time series databases fit in an MRO strategy

Common MRO challenges

Fragmented Spending

Reactive Maintenance Culture

Poor Data Quality

Excess and Obsolete Inventory

How to improve an MRO strategy

Wrapping up

What does MRO stand for?

What is MRO in business?

What is the difference between MRO inventory and production inventory?

What is MRO in manufacturing?

What is MRO in aviation?

What are MRO supplies?

Why is MRO important?

What is the difference between preventive and predictive maintenance?

What is a CMMS and how does it relate to MRO?

Telegraf Enterprise Beta is Now Available: Centralized Control for Telegraf at Scale

What is Telegraf Enterprise?

Meet Telegraf Controller: your Telegraf control plane

Configuration Management That Doesn’t Collapse Under Growth

Fleet-Wide Health Visibility

Designed to fit your telemetry stack

Why we’re running this beta

Enterprise support that matches production expectations

Who is Telegraf Enterprise for?

Packaging: free and enterprise options

Telegraf Controller

Telegraf Enterprise

Getting started with Telegraf Controller

Unifying Telemetry in Battery Energy Storage Systems

The operational reality of modern BESS systems

The fragmented reality of BESS telemetry

Operational cost of data silos

What unified telemetry actually means

How unified telemetry works

Operational impact

ju:niz Energy Deployment

The bottom line

A New Scale Tier for Time Series on Amazon Timestream for InfluxDB

Scaling for the mission-critical

Architected for enterprise demand

The foundation for physical AI

What’s next?

What is Industry 4.0? Everything You Need to Know in 2026

The path to Industry 4.0

First Industrial Revolution

Second Industrial Revolution

Third Industrial Revolution

Fourth Industrial Revolution

Industry 4.0 key concepts and principles

Interoperability

Virtualization

Cyber-Physical Systems

Decentralization

Modularity

What technologies are driving Industry 4.0?

Internet of Things

Cloud Computing

Edge Computing