Minting and availability
A pool has to be online 100 % of the time. If it is offline or unreachable at the moment it should mint a block, that block is missed and the pool's performance drops. Keeping every assigned block is the main job of a stake pool operator.
The tricky moments are updates, and running short on resources such as disk space or memory. Wrong configurations can also lead to missed blocks.
How OCTAS handles this
OCTAS runs several redundant nodes in the background, so they can be upgraded one after the other while the backup nodes keep minting. The hardware also scales at runtime, without shutdowns or restarts 🥳
Luck: minted blocks versus expected blocks
The Cardano protocol assigns blocks to a pool in proportion to its stake, but completely at random. There is only a tendency towards an expected number of blocks per epoch; the actual number drifts up and down. The operator can't influence this, only make sure every block that arrives gets minted.
Since late 2020 the operator can calculate in advance how many blocks the pool will get in an epoch, and at which time. That's what the block schedule on the rewards page shows.
Over many epochs this tends towards a normal distribution, so bad-luck epochs are compensated by lucky ones sooner or later, and the other way around.
Example: epoch 220
The expected number of blocks was 13, but only 9 were assigned. That has a small probability of 5.64 %, the same as getting 17–18 blocks 😳 After bad luck like this, the chance of a lucky epoch soon after rises.
Timing within the epoch is random too. In epoch 220, OCTAS made 3 blocks within 2 hours at the start of the epoch, then only one block in the next 84 hours, then 5 blocks close together.
To follow the current epoch live, open the monitoring dashboard of the OCTAS block producer 👍