Insight · freshness incident
HU data outage case study: how Alvo made a data gap visible.
This is not a blame post. It is an operating read: the upstream CC-BY HU series had two full local days of null prices, LEAR lacked lag-1/2/3/7, and Alvo chose skip-not-fabricate plus a visible breached SLA.
Insights
In brief
Energy-Charts HU returned null prices for the full 2026-06-30 and 2026-07-01 delivery days: 192 null 15-min points; PL was unaffected.
The adapter dropped null points and incomplete days, so HU forecast capture skipped instead of being imputed.
Point-in-time HU forward captures for delivery 2026-07-01/02/03 are not backfillable: later reconstruction is no longer a morning forecast.
At 2026-07-02T17:11Z, live `/status` showed `FORECAST_DA_CAPTURE_HU` breached: 296.7% budget, +59h overdue.
Two full days of null prices, not one bad hour
The 2026-07-02 investigation began with one fact: `forecast-da-capture:HU` was stuck at 2026-06-29 while UA and PL continued daily capture. The upstream check showed `api.energy-charts.info/price?bzn=HU` returning null prices for every 15-min point on delivery days 2026-06-30 and 2026-07-01.
The wording matters. We do not call the source broken and we do not infer intent; we record the data gap: HU had 192 null points, PL did not have the same gap, and the 2026-07-02 HU data returned later in the morning.
Skip-not-fabricate was the right decision
The Energy-Charts adapter drops null points and keeps only complete 24-hour days. That is not pessimism; it is the contract. The downstream forecast expects 24 hours, and a ragged day would make the shape incomparable.
The served LEAR estimator needs lag-1/2/3/7 same-hour prices. With 2026-06-30 and 2026-07-01 missing, the HU p50 for delivery 2026-07-03 was not computable. Alvo did not substitute a neighbor market, interpolate, or present synthetic capture as a real forecast.
What self-heals and what is permanently lost
The system self-heals when the gap leaves the lag window: the incident runbook expected HU capture to return for delivery 2026-07-05 at the latest, assuming later days were complete again. A retry policy cannot create data the upstream did not provide at the decision time.
The permanent loss is different: forward captures for delivery 2026-07-01, 2026-07-02 and 2026-07-03. Backfilling them later would answer a different question. The point-in-time archive asks what was known in the morning before a decision.
Product lesson: observability beats silence
Before this incident, provider freshness covered high-level provider rows, but not per-zone forecast capture. The three-day HU gap was found by a manual DB probe, not by an operator-facing surface.
After the fix, `/status` shows `FORECAST_DA_CAPTURE_HU` as its own freshness SLA row beside UA, PL and JAO. This is not a prettier dashboard; it is a product-truth surface that tells the desk HU is temporarily not displayable, why, and that it returns automatically when the data becomes evaluable again.
Insight · freshness incident
FAQ
Was this an Alvo outage?
No. The root cause was an upstream data gap for HU; the Alvo guardrail that dropped null and incomplete days behaved correctly.
Why not backfill the HU forecast later?
Forward capture records what was known at the morning decision time. Once the missing facts arrive, the result is a retrospective reconstruction, not a forward forecast.
What should an operator see?
`/status` should explicitly show `FORECAST_DA_CAPTURE_HU` as breached until the lag hole leaves the window and capture returns.
Sources and next steps
Workspace
Want to check the current state?
Open `/status`: it shows live SLA rows for forecast-capture zones, JAO and platform-only signals.
Open status