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, the then-operational `/status` (now `/admin/readiness`) 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, `/admin/readiness` shows operators `FORECAST_DA_CAPTURE_HU` as its own SLA row beside UA, PL and JAO; public `/status` exposes only the aggregated forecast group. This preserves product truth without revealing internal configuration.
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?
`/admin/readiness` should show `FORECAST_DA_CAPTURE_HU` as breached until the gap leaves the window and capture returns; the public forecast group stays degraded.
Sources and next steps
Workspace
Want to check the current state?
Open `/status` for aggregated freshness; exact forecast-zone and JAO SLA rows are available to authenticated operators at `/admin/readiness`.
Open status