Leaderlogs is the best way to know for upcoming blocks. Your lifetime luck is still normal really, it’s “only” at 93%. Once you get the next blocks your luck will jump up above 100% again and you’ll be back on average.
It’s possible you missed a block a while ago and not caught it with the leaderlog checks. When you’re low on delegation each single block is so important. It’s not a nice feeling though.
Thanks for your response - I have always run the leaderlog checks since starting my Stakepool so I know that I have not missed any. This really is a run of 21 Epochs without being assigned leader 
22 Epochs now without being assigned as slot leader - average delegation during this time around 300K - current delegation 270K
At what point does this stop being just poor luck? - in fairness to my delegators I can’t keep going like this and will have to advise them to go to other pools soon - there has to be something basically wrong with a protocol that can basically kill hard working pools like this.
If you make sure there are no other problems,
delete db, resync
Thanks - appreciate the idea but why would re syncing a database have any affect on the allocation of slots? This must be based on the registration status and current stake?
what is your pool name?
GrahamsNumberPlus1 or ticker GNP1
23 Epochs now and no blocks assigned !!! - maybe I delete and resync database but not sure why that would make any difference
24 Epochs now and no blocks assigned !!
Can anyone advise or take a look at my pool - the odds are way to high and there has to be something wrong?
Just for the avoidance of doubt I do not believe this issue has been solved. I have a Stakepool configured correctly that is no longer being allocated slots. I had 26 blocks minted in a fairly regular fashion for 18 months and none since moving my pool to a new server in the cloud. While it is possible this is just exceptionally poor luck (less than 1 in 500) given the fact this has only happened since moving my pool I believe that it is highly likely that there is another issue at play here - I continue to reach out to the community for ideas as I am getting to the point where I will have to retire my pool soon if I cannot find a solution. Many thanks
Can you please flag them so that we can remove those users?
definitely - thanks
Since only the stake pool id and the VRF key go into the leaderlog computation, there is not so much that even can be the issue.
You said above that you checked the hash of the VRF key? Also that skey and vkey belong to each other?
If you are using the wrong stake pool ID – one with a lot less stake – that could fit the behaviour you are seeing.
Thank you for providing help here - it is much appreciated. I have checked my pool id in the /priv/pool/GNP1 folder and it is the same as what is registered on the network. I have checked the hash of the vrf.vkey and again it is the same as what is registered on the network. I am not sure how I would check that the skey and vkey belong to each other but these are the only two vrf keys that I have which were created when I set up the pool so I would assume that they have to be. So not sure what else I can really check in this area.
I am getting quite concerned about this now and I am afraid this may never be solved. The reason is that I am now starting to lose the remaining stake that I have and as I do so the chances each Epoch of being selected will naturally become less and approach 0. While everyone is suggesting this is just based on luck I cannot help but think something else may be wrong and the sad thing about it is that I may never really know.
25 Epochs now and still no blocks assigned!!!
With an estimated block odds of 0.24 I am doubting this is just poor luck
I am bit surprised that there is not more interest with regards to this from the development team. At what point do we start to question the protocol? when the odds are 10,000,000 to 1 instead of 1000 to 1?
The question has to be asked is why did my pool mint 26 blocks in a reasonably regular fashion and now has just stopped being included in the protocol for 25 Epochs?
26 Epochs now and still no blocks assigned!!!
What the heck has happened? Why does a perfectly functioning Stakepool which successfully minted 26 blocks over 18 months or so suddenly stop being allocated blocks for 26 Epochs after having an average stake during these 26 Epochs of 300,000 ADA?
Did you also check that this folder is really the one used in env? There should be a line POOL_NAME="GNP1" there. (Assuming that you are using CNTools, since Coincashew doesn’t have those /priv/pool/ subfolders.)
You have made the impression that you really checked everything. So, really, really bad luck is the only explanation left. But that’s easy to say, since it’s not my own pool.
There was another thread here lately with pools with bad luck:
But, from those MOTO by @Judofish and AZ5 by @dvekris had blocks in the meantime: https://adapools.org/pool/d5e493b834ee233104cff9d141ffae2d8d76a563f829e78987540046 and https://adapools.org/pool/11049c12ebde61e94531eb2d022b44ba4fdbc48eea14bf6cbf2a6f44
PLBPL by @nanap also has an ongoing stream of bad luck: https://adapools.org/pool/51120922fb9d7c0ecbb20378950da7880cb6dd9d3c9e06e17bff6aca Not as long as yours, though.
If there is a problem with your pool, it is very rare and well-hidden.
They don’t usually read the forum that intensively.
There was also this thread lately, where cncli gave a wrong leaderlog, because the database was not up to date if I understood that correctly:
Did you continue to cross-check with cardano-cli query leadership-schedule?
Thank you for your time with this - I really appreciate that - to answer your questions - yes I do have the line POOL_NAME=“GNP1” in the env file and I have checked that it is not commented out - #POOL_FOLDER=“${CNODE_HOME}/priv/pool” is commented out but that should not matter as everything is set up as the default settings used for cnTools.
Also yes I do check using the cardano-cli query each time and just get an empty result
This is getting really difficult now as I am not sure what I should say to my delegators - is there anyway I can contact someone from the development team to look into this as if this is a very rare and well hidden issue it would have to be in the interest of all pool operators to know. Once again thanks