What if You Put Prometheus on an Electrical Panel? Observability Belongs in the Power Room Too

Picture a Kubernetes incident. The service gets slow. But you don't know CPU. You don't know memory. You don't know what the network is doing. There are no logs.

At that point an operator has almost nothing to work with. Walk over to the box and look at it. Reboot it and hope. In IT we don't call that a production environment. That's why we scrape metrics with Prometheus, draw them in Grafana, and page ourselves through Alertmanager.

Then one day I was staring at a distribution panel and thought: why don't we run electrical equipment like this?

I'm not suggesting you bolt Prometheus onto an actual panelboard. What I want is to take the philosophy behind Prometheus and point it at electrical systems and factories.

Electrical equipment is already producing metrics

A server gives you plenty to watch.

CPU Usage
Memory Usage
Disk I/O
Network Traffic
Temperature
Request Count
Error Rate

We express the state of a server as numbers. So what about a distribution panel? The panel and everything wired to it already carry physical values.

Voltage
Current
Power
Energy
Power factor
Frequency
Temperature
Breaker state
Per-circuit load

The difference is that servers have been aggressively instrumented for years, and most electrical equipment hasn't. The electricity was always flowing. We just weren't watching it.

Looking after the failure is not the same as looking before it

Say a machine normally draws around 20A. It doesn't break one morning out of nowhere. It drifts.

20.1A
20.3A
20.8A
21.5A
22.7A
24.1A

The machine still runs. To the operator on the floor it's fine. The breaker hasn't tripped. From the data's point of view it's a different story. Something is changing.

Server ops works the same way. If CPU normally sits at 20% and you see

20%
25%
35%
50%
70%
85%

you go look, incident or no incident. That's what monitoring buys you.

Monitoring and observability aren't the same thing

Worth pushing one step further. Monitoring usually watches values you decided on in advance. Is CPU over 90%? Is the temperature over 70°C? Is current above the configured limit?

Observability is broader. It's closer to being able to reason about what's happening inside a system from the data it emits. When a server breaks, you don't stare at CPU alone — you read CPU, memory, network, logs, and request latency together and work backward to a cause.

Electrical equipment deserves the same treatment.

Current rising
+
Temperature climbing
+
Power consumption pattern shifting
+
Repeating at the same time of day

When those show up together, you're seeing far more than "the current is high."

Treat the panelboard like a Prometheus exporter

Let me redraw this in a shape IT people already know. Prometheus scrapes metrics from a lot of systems. Put electrical equipment in that same shape.

[Electrical equipment]
     │
     ▼
[CT / power meter / temperature sensor]
     │
     ▼
[Gateway / Edge Device]
     │
     ▼
[Metric Collector]
     │
     ▼
[Time-Series DB]
     │
     ├── Dashboard
     ├── Alert
     └── Analytics

In our vocabulary, you're hanging an exporter off the equipment. In practice the field work is Modbus, MQTT, OPC UA — whatever fits the site. What you collect can land in something Prometheus-shaped or in any other time-series platform.

The product name isn't the point. Turning equipment state into metrics is the point.

So what shows up in Grafana?

Say a plant has 30 distribution panels. Pull data from each of them and from the major machines, and one screen gives you this:

Plant-wide power consumption
Power by process
Load by machine
Temperature by panel
Per-circuit fault state
Peak by time of day
Day-over-day / week-over-week / month-over-month
Abnormal consumption patterns

The old sequence: something goes wrong, a technician walks out to the floor, opens the panel, puts a meter on it, and leans on experience to find the cause. With data, the order flips.

Dashboard → locate the anomaly → inspect on site.

This doesn't replace field experience. It hands the experienced person the information they need before they start guessing.

Alertmanager is where it gets fun

Nobody watches a dashboard all day. When something goes wrong the system should say so. You write rules:

Panel temperature > threshold
→ notify the facility manager

Machine current > normal range
→ notify the equipment owner

Overnight power consumption spikes
→ energy anomaly alert

A circuit stops reporting data
→ check the sensor / link

We've been doing this for years in IT ops. Your phone doesn't ring after the server dies; the system catches it first. The same idea carries over to electrical equipment unchanged.

Baselines matter more than thresholds

A plain threshold only gets you so far. Suppose you alert when current goes over 30A. On machine A, 30A is a normal day. On machine B, 30A is already dangerous. Even on the same machine, the normal range moves with production volume and time of day.

Once enough data piles up, something more useful appears. A baseline. What does this machine normally look like?

A normal Monday morning
A normal night shift
A normal peak-production run
A normal idle window

Once you know that, you stop judging by absolute numbers and start asking whether today looks different from usual. And that's exactly where statistical analysis and AI plug in naturally.

In manufacturing AX, this comes before AI

Manufacturing is full of AI talk right now. Vision AI, predictive maintenance, digital twins, AI agents. My worry is that people run the order backwards.

AI
↑
Analysis
↑
Data
↑
Collection
↑
Sensors
↑
The floor

AI sits on top. No bottom, no top. Without sensors, AI has no idea what the equipment is doing. If you never stored the data, there's no history for it to learn from. If equipment data and production data aren't linked, it can't reason about causes either.

Which makes the start of manufacturing AX surprisingly unglamorous. Make the factory observable. That comes first.

The scope grows from one panel to the whole plant

This is where it gets interesting. It started with a single distribution panel. The same structure drops straight onto everything else.

Distribution panel
→ power

CNC
→ runtime / load / alarms

Laser cutter
→ utilization / job time

Press brake
→ throughput / wait time

Compressor
→ pressure / power / runtime

Plant
→ temperature / humidity / energy

Then you wire in production data.

Equipment data
+
Power data
+
Output
+
Defect rate
+
Job time
+
Order info

At that point you're no longer telling a "smart panelboard" story. You're telling an observability story about the entire plant.

Take a sheet metal shop

Steel comes in. It gets laser cut. Bent. Welded where needed. Painted. Assembled, inspected, shipped.

On the surface these are separate manufacturing steps. Look at it like an IT system and it's one pipeline.

Order
 ↓
Design
 ↓
Material
 ↓
Cutting
 ↓
Bending
 ↓
Welding
 ↓
Painting
 ↓
Assembly
 ↓
Inspection
 ↓
Shipping

Which changes the questions you ask. Where does work sit waiting the longest? Which machine is the bottleneck? How much electricity actually goes into one finished unit? How many hours is a machine running without producing anything? What moved in the data before the defect rate climbed?

You need to be able to answer those. We trace a service's request flow in IT. In manufacturing you trace the flow that produces the product.

Manufacturing AX starts with making the plant visible

Say "smart factory" and people picture robots swinging around and AI running production on its own. There's a much more basic question before any of that.

Can you explain, with data, what is happening in your plant right now?

If you can't, automation is going to be rough. You can't optimize what you can't diagnose. So I think about manufacturing AX the way I'd think about an IT system:

Digitization
↓
Connectivity
↓
Observability
↓
Analytics
↓
AI
↓
Automation

Digitize first, connect second. Observation and analysis build on top of that. AI and automation come last.

What "put Prometheus on a panelboard" actually means

Back to the original question. Can you put Prometheus on a distribution panel? Technically, sure — use real Prometheus, or use an industrial platform instead. The product name was never what the question was about.

What I'm after is one thing: why do we treat observability as table stakes for servers and skip it entirely for production equipment?

Turn equipment state into metrics and store them over time. Watch them on a dashboard and detect anomalies. Link them to production data, and let AI reason on top of that. Seen this way, a distribution panel stops being an electrical product. It becomes one of many data sources that tell you what the plant is doing.

And that one small metric from a panelboard grows into a system that watches the whole factory. Maybe manufacturing AX doesn't start with a giant AI project after all.

Make the invisible factory visible first. That's where I'd start.