Insight · freshness incident
HU data outage case study: how Alvo made a data gap visible.
For two days the source for Hungarian prices returned no data. Alvo did not invent prices: the HU forecast for those days was skipped and flagged, not filled in.
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 operations panel 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: the HU forecast capture was stuck at 2026-06-29 while UA and PL continued daily capture. The upstream check showed the Energy-Charts price endpoint for 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 then-served LEAR estimator needed 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, the internal operations panel (Alvo team only) shows HU forecast capture as its own SLA row beside UA, PL and JAO; the public /status page shows only the aggregated forecast group, without internal configuration.
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 does the Alvo team see?
The internal operations panel shows HU forecast capture as breached until the gap leaves the window and capture returns; meanwhile the public forecast group on /status stays degraded.
Sources and next steps
Workspace
Want to check the current state?
Open /status to see data freshness by group.
Open status