The problem is not in the code, otherwise we'd have issues every week. As proven in the past, the problem lies in data access; input and output of data is sometimes stopped due to locks and slow readings, all very much affected by our already gargantuan database getting larger and larger every season. Some data just gets accessed slower and slower, and in some pretty unlucky cases, things get so tangled up that a read or write is stopped. This then affects everything after that, corrupts other data, procedures don't properly clean up after themselves and inserts fail due to double data entries...
It gets even more technical and convoluted but that's basically what happened that Saturday, a insert of some rather unimportant piece of data (SMS reports) broke the chain and some very important data was not entered. Sadly, there's not much I can do about the missing data, but I reordered stuff so that if it breaks again at the same place, it won't affect anything else after that.
Our plan is to move the database to a faster and more stable environment. If testing goes as planned, I think we'll be able to accelerate IO so much it will be good for many, many years ahead.