It is back on track - it went down due to a parse error in a data exchange between BOINC and BURP backends. It was designed to fail in this situation to make sure a human being looked at the issue before things moved on. Luckily it was nothing bad.

Same issue with data in the shared memory segment between BOINC and BURP only being partially filled out, causing the BURP queue and scheduler manager to go into panic-mode after retrying 10 times because the numbers don't add up. This stops much of the process revolving around workunit creation and workunit handling in general.

The BOINC scheduler keeps a list of workunits that are ready to send in a memory segment on the server. BURP monitors this segment and makes sure that there is a good balance of different workunits so that high-mem WUs don't block low-mem WUs etc.
This list is of a certain maximum size - currently around 300-450 slots - more than enough to hold a small cache of all the different kinds of workunits that clients can ask for.
When a client gets sent a WU it is removed from the memory and the memory slot is temporarily empty until a new WU can be prepared and loaded into the slot.

What has happened twice now is that a safety measure in the part of BURP that monitors this memory segment and calculates the number of occupied slots plus the number of empty slots has come to the conclusion that the total number of those two kinds of slots combined does not add up to the total size of the list anymore.
It turns out there is a third kind of slot, the partially filled or partially empty slot.
I'll have to dig into why we see these partial entries in memory more often than usual right now - and where they come from. They don't really seem to do anything bad, though, so this is mostly just erring on the side of caution.