There was a time based bug in spigot, this has been fixed in the latest builds. Download: http://ci.md-5.net/job/Spigot/lastSuccessfulBuild/artifact/Spigot-Server/target/spigot.jar Backports to older versions: 1.7.2: http://dl.thinkofdeath.co.uk/spigot/spigot-1.7.2-R0.4-SNAPSHOT.jar Mirror: http://dl.gunfighterj.com/spigot-1.7.2-R0.4-SNAPSHOT.jar Mirror: http://solderrepo.rainbowcode.net/spigot-1.7.2-R0.4-SNAPSHOT.jar 1.7.2 (Protocol Update): DMCA Removal 1.6.4: http://dl.thinkofdeath.co.uk/spigot/spigot-1.6.4-R2.1-SNAPSHOT.jar Mirror: http://dl.gunfighterj.com/spigot-1.6.4-R2.1-SNAPSHOT.jar Mirror: http://solderrepo.rainbowcode.net/spigot-1.6.4-R2.1-SNAPSHOT.jar 1.5.2: DMCA Removal More info (by md_5) Early Wednesday night (Australian time), we received our first reports of this issue occurring. A user's server had crashed with the now widely known stack trace (this user was from New Zealand, which becomes important later). The apparent cause of this was unknown, somehow the currentTick variable had become negative (how exactly can the server be currently at a negative tick!). Whilst I was not awake at the time, the issues became more and more apparent as clocks started to roll over. @Thinkofdeath quickly prepared a fix and the bug was resolved from our point of view. Unfortunately not everyone updates to every new build instantly, so the bug persisted, and eventually almost every server was affected as time went on. The actual cause This issue is a combination of two factors, the way in which CraftBukkit keeps track of the current tick (https://github.com/Bukkit/CraftBukkit/commit/c1a47990408eda27f985c79e7ad6fbeadc8fc338) and the way in which our enhanced tab ping code (which enables latency updates for the tab list) works: https://github.com/SpigotMC/Spigot/commit/fdfc07bd39322ece7c9700b46578e591115a34e5 We use this current tick variable to select which player we should send an update for. Using this seemingly monotonic counter enables a predictable and consistent update order. However unfortunately for us, instead of starting at 0 and counting upwards as the server progresses, the current tick is actually based on the current time in order to preserve behavior of some checks when the server is running slow. Whilst the current time is a long, the current tick is only stored as an integer. This means that every so often (roughly every 7 years) it will overflow, making the server state that the current tick is negative. Whilst this likely causes some of the code within the server to malfunction the tick it overflows (such as the aforementioned movement speed check, it doesn't really cause any other issues with stock behavior. Unfortunately however, our tab list patch expected this variable to be always positive (it is currentTick after all!). Once this variable became negative, we would try and look up negative indexes in the player list, causing a crash. Further Science The currentTick function works by taking the current Unix time in milliseconds, and dividing it by 50. As this long result is packed into an integer, it will eventually get too large and overflow the integer. This happened at exactly Wed, 26 Mar 2014 20:06:11 UTC: at Unix time 1395864371199 all was good, however at 1395864371200 it overflowed and became negative. This overflow will happen again at 14 Jan 2021 08:25:36 GMT (thanks @sk89q and @ams2990 for these calculations.) Given the time influenced nature of this very obscure bug, no amount of quality control or testing before Wed, 26 Mar 2014 20:06:11 UTC would've uncovered it, however after that date it would have been very apparent indeed. Thanks to all the people who helped research and fix this bug, as well as you guys for your continued support. ~Spigot Team PS: In the event that either session, login, or other Mojang services are having issues, please refrain from contacting Mojang employees directly. You can follow their twitter feeds for updates and check https://help.mojang.com/ for status updates, however, directly contacting employees does not help the situation and should be avoided.