Availability & Production
The red ceiling is what the plant told the market it could deliver. The blue is what it actually sent to the grid. Grey in between is capacity that was declared available but not produced. All times are Estonian time.
Outage log
Every Urgent Market Message published for Auvere since the plant launched in May 2015.
| Type | Start | End | Duration | Capacity | Reason |
|---|---|---|---|---|---|
| Loading outage log… | |||||
Myth Buster
Two questions about Auvere and the electricity price, checked against every matching event on record. These are limited comparisons, not proof of cause: prices move for many reasons at once, and nothing here isolates Auvere's effect from everything else happening in the market.
Two things skew both comparisons in the same direction: Auvere's market share is under 20%, so its own output rarely moves the price by much on its own; and Auvere is usually started only once the price already covers its cost of production, so a price that's already high or rising is often the reason Auvere started, not the result of it.
Loading simulation data…
About this website
This website started out as a joke between me and my friends. One of the guys said "this Auvere is broken all the f***ing time". I'm more of a data guy myself and wanted to bring some actual facts to this discussion. Now everybody has the chance to draw their own conclusions.
For people who've never heard of Auvere Power Plant — it's a notoriously expensive and fragile oil shale burning power station in Estonia. It's becoming a national sport to bash it.
Seemingly burning question — why isn't this site in Estonian? When I initially started to gather the data, I noticed that UMMs are in English. It would be kinda weird for the rest to be in Estonian and so it went.
If you think it's informative/funny/critical/civil disobedience (I think it's all of it) and want to make a gesture — you can buy me a coffee. If and only if you spot a bug, you can report it to gmail user elektriturgonkatki.
I really do put considerable effort into making sure the data is correct, but… it's complicated. I didn't start this expecting to make decisions regarding how some of the hottest facts in Estonian energetics are presented, but here I am. Read the changelog for examples — although this is a tiny fraction of it.
Before you go on your next social media frenzy raving about uptimes, notice this text on the gates of Auvere industrial complex — it says: "Days without traumas — 160". Having visited the older plants and mines, I have nothing but respect for the people working there and putting their well-being on the line to bring us electricity — even if it's expensive.
Detail from a photo by Eero Vabamägi (hope this is acceptable use).
Changelog
-
10. September 2026
Version 2.1.1
Switched to using Entso-E XML API after their API changes. The changes broke the Python library I used before.
-
2. September 2026
Version 2.1.0
Version 2.1.0 added the Myth Buster functionality exploring price changes arounds Auvere's failures and startups. Also numerous small bugfixes (layout, wording, labels). Added data freshness indicator in the footer.
-
26. August 2026
Version 2.0.0
Version 2.0.0 completely overhauls the whole site. The main idea is to show availability and production on the same chart. Then just let the user choose period and show the stats calculated for that period. One thus has access to both current week and all time stats at once.
-
21. May 2026
Version 1.0.0
Fixed a critical bug where my code took the status from the first version of a UMM, but a later version of the message cancelled the whole chain. This affected 19 UMMs and moved the full-capacity needle 1.2% to the positive side (previously: 2007 days, now 2052 days). It removed 0.5% of reduced-service status (previously: 545 days, now 524 days) and 0.6% of not-operational status (previously: 1485 days, now 1462 days). I apologize for the mistake. As I've said before, my intention is not to make Auvere look bad or worse than it is — I do my best to provide correct data. But things happen and I try to be transparent about that.
I called this version 1.0.0 later as I wanted to draw the line between this and the next.
-
15. May 2026
Version 0.10
I switched from Gemini to Claude and kinda got back my joy of developing this site. Implemented the Outage Log tab where you can browse all Auvere's UMMs yourself. Fixed some long-time annoyances (like tooltips not working on mobile) and made some subtle changes here and there. Noticed the favicon?
-
13. May 2026
Version 0.9.2
v0.9.2 fixes an error which caused middle statuses in a UMM chain to be ignored. For example, the events on 6 and 7 May both contained station ramping up, then failing, then coming up again. Now the failure in the middle is counted too. This affected the heatmap and predictive model; overall stats were not affected. The new approach counts 38 more failures (over 11 years), making the predictive model even more pessimistic.
-
22. Apr 2026
Version 0.9.1
v0.9.1 fixes an error related to UMM classification. The issue didn't affect any statistics except the predictive model, which is now a bit more conservative. It was discovered during the maintenance window on 21 April.
-
10. Apr 2026
Version 0.9
v0.9 fixes four bugs:
- Different end dates of the current outage displayed in different places. The status panel used the next UMM in the chain, not the last. Now both the status panel and progress bar agree.
- The next-maintenance banner also took the next UMM in the chain, instead of looking at the next maintenance after the chain ends.
- The 7-day market chart previously took the "production by type" report and subtracted Auvere from the all-oil-shale blocks, but since "production by type" data lags individual data, the other blocks were underreported. Now "other oil shale blocks" is the sum of individual blocks, not what remains after subtracting Auvere.
- The market-share calculation previously calculated a percentage of Estonian production; the new version calculates a percentage of supply — that is, including imports. I have yet to figure out which number is more important. It shows two things: Auvere is a considerable amount of local production, but we're still heavily dependent on imports.
-
05. Apr 2026
Version 0.8
v0.8 completes the loop by adding production data. For a long time I've been contemplating how to do it properly — I wanted a clear separation between the status of the plant (availability) versus what it's actually doing (production). The initial idea was to add production data to the heatmap, but then there is also the economic-standby status, which would have made it very cluttered. So now the production part is completely separated, and I think it's interesting in its own right. All the "statistics cards" are also reworked. While the main charts are 100% actual-data based, the stats cards switched to more derivative indicators. Most of the previous numbers are now available from various tooltips, and the new parameters are more "discussion points". Because Auvere's fuel-mix data isn't available, the following figures are more speculative than the rest of the dashboard:
- Oil shale burnt — based on a gradient where the oil-shale part is decreasing and biomass increasing
- CO2 released — based on the previous estimate
- Ash — also based on the oil-shale-burnt estimate
- Carbon tax paid — a derivative of CO2 released
- Missed revenue — sums hour × price when output was below 80% and the market price was above the carbon-tax threshold
-
28. Mar 2026
Version 0.7
v0.7 does a lot of things to work around the absolute abomination that is the ENTSO-E API. It's throwing 503s whenever it wants — not like a maintenance window, it's happening constantly — it returns partial data, some batches are missing, and so on. This totally messed up the market-tab charts: there were times when Finnish import was missing but export to Latvia showed (messing up the net flow), Auvere data was missing but aggregated into the rest of the oil-shale blocks, and so on. The new version switches to more granular data blocks (weekly instead of monthly), adds block retries and fallbacks, but I'm sure there are cases even this doesn't help.
-
09. Mar 2026
Version 0.6
v0.6 adds a predictive model showing probabilities of survival over a period of time. The counter starts from the previous UMM with status BROKEN, not the last red day on the heatmap. This is a bit counterintuitive, but look at the heatmap tooltips — it's a common case for a BROKEN status to end and then a MAINTENANCE ticket to be logged for the start-up procedure. Also switched to a weighted-average algorithm when calculating each day's status on the heatmap.
The plot illustrates the Weibull distribution used for the predictive model: days survived on the x-axis, count of runs with that many days, and the Weibull survival function fitted over the ten-year data.
-
08. Mar 2026
Version 0.5
v0.5 feels like the first stable release. Added the Market tab. Fixed some bugs, tuned some algorithms. The streak-calculating algorithm was heavily affected by rapid-fire UMMs that come with outages — sometimes there are very short delays in between that break the streaks and bring averages down. I know the numbers have been changing one way and then the other, and that isn't good in the trust business. But then again, every iteration I've made feels more fair than the previous one, regardless of which direction the numbers move. It's not my intention to make things look good or bad; my intention is to provide as accurate information as I possibly know how to provide. And there is a lot of nuance to it — there always is, when you dig deep enough.
-
04. Mar 2026
Version 0.4
Status algorithm overhaul. The previous algorithm looked at UMMs and painted the period red for a BROKEN status, yellow for MAINTENANCE, and green for uptime. This penalized the station whenever a UMM was logged, even if capacity was only slightly reduced.
I decided to ditch the BROKEN/MAINTENANCE distinction and make the algorithm capacity-aware. The new mapping is:
- Green: full capacity (≥ 250 MW)
- Yellow: reduced capacity (50–249 MW)
- Red: not operational (< 50 MW)
The max capacity stated in a UMM is like a speed limit on a German highway: if there's no limit, you can go as fast as your plant allows (Auvere is capped at 274 MW). If there's a limit, your actual generation can be lower, but you shouldn't exceed it. It's strictly an upper bound, not what the station actually generates at any given time.
We're looking at periods when this upper limit is set, since that invariably means there's a problem. I tuned the ranges to allow for normal fluctuations (260 MW is still fully operational). The cap rarely drops below 50 MW without hitting 0 MW — 33 times, to be exact. Since anything under 50 MW is below the boiler's minimum stable load, the plant is functionally offline at that point.
I expected the differences between the algorithms to be larger — capped operation is less common than I thought. Regardless, the capacity-aware algorithm is a significant improvement. Here's a graphical representation of the differences:
The gap at the beginning represents the period when station output was capped due to dust emissions.
An interesting plot from testing the new algorithm. It shows the station tripping, a few attempts to restart at a 100 MW cap, a maintenance period, and a stepped startup. My initial algorithm used only the very last UMM in a chain (here setting the cap at ~225 MW), which masked the initial downtime and made the station look considerably better. Tracking the exact steps exposed the reality.
Smaller things: reworked the maintenance-messages panel and the aggregate stats to fit the new calculations. Not entirely happy with it yet, but I wanted to push the status overhaul out and deal with smaller adjustments on the fly.
-
01. Mar 2026
Version 0.3
During maintenance with reduced capacity (plant partially working), the pie chart with actual production is still shown. Added comparison and changelog pages.
-
23. Feb 2026
Version 0.2
v0.2 was the first version to actually experience an Auvere outage (I don't have any test data), so multiple issues were fixed on the fly when maintenance started. v0.2 uses the 12:00 status check only for the heatmap, which I consider good enough — averages are based on actual periods (uptime is broken by a 2h restart in the middle of the night). Added yearly status breakdown to show whether the plant is improving or not. Added a lifetime-stats pie chart. Added ongoing and upcoming maintenance messages. There's a known deficiency which makes uptime figures worse — in some cases maintenance messages are logged when the plant is operating at reduced capacity, and the current algorithm still counts it as downtime (but then what should the threshold be?). The difference is shown below (the capacity-aware approach uses a 50% threshold).
-
17. Feb 2026
Version 0.1
v0.1 used the following algorithm for the heatmap and stats: if the plant was up at 12:00 (no maintenance messages logged that cover 12:00), the plant was considered up for the whole day. This caused significant skewing of averages and streaks — you might notice this in an early screenshot published on kroonika.delfi.ee.