A balancing market dashboard, end to end

One screen showing what the power system is doing right now: system imbalance, reserve activation, renewable output against forecast, prices across markets. Built for our own trading, then hardened until it could be left alone.

What this energy dashboard software actually does

It is real-time energy monitoring for a trading desk: live imbalance, activated reserves, prices and position, refreshed as the data arrives rather than on a schedule. A monitoring dashboard for people whose next decision is fifteen minutes away.

The problem

A balancing position is decided from numbers that live in four different places, publish on four different schedules and use four different formats. By the time you have opened the tabs, the quarter hour you cared about is over.

The requirement was simple to state and unpleasant to build: everything relevant on one screen, never more than a minute stale, and it must not lie when a source goes down.

What it shows

The engineering that took the time

Sources fail differently

A SOAP endpoint times out. A REST feed returns 200 with an empty body. A platform serves yesterday's file under today's name. Each needs its own detection, and the dashboard must show stale rather than silently draw an old number as current.

Parsing was the bottleneck, not the network

One source publishes large spreadsheet files. The obvious library took seconds per file, which is fine once and unacceptable every minute. Reading the container directly and streaming the XML inside made it 30 to 50 times faster and turned a background job into something that runs inline.

Caching that survives an outage

Stale-while-revalidate throughout: serve the last good value immediately, refresh behind it, and mark the panel when the refresh has been failing. The dashboard keeps working through a source outage instead of going blank — and it says so.

Timestamps are the whole game

Every value carries when it was published, not only what period it describes. That is what makes the same pipeline usable for backtesting later: you can reconstruct exactly what was on screen at any past moment.

What it runs on

• Python backend translating REST calls into SOAP, AMQP and file fetches, with per-source retry and backoff.
• Plain JavaScript and Canvas on the front end — no framework. The page is a few hundred kilobytes and repaints without stutter on a phone.
• Static output where possible, so a backend restart never takes the screen down.
• Cloud deployment with a keepalive, because the platform sleeps idle services and a trading tool cannot take thirty seconds to wake.

What it would take for another market

The architecture is market-agnostic; only the adapters change. For Germany that means SMARD, Netztransparenz and regelleistung; for Britain, Elexon and NESO; for France, the RTE portal. We have written up each of those in our market data guides.

A first working screen against live data is typically two to three weeks. Everything after that is adding panels and hardening.

Frequently asked questions