I get it a lot and I have a pretty good guess as to why it happens. Every zone in the game, including Cyrodiil is sharded into slices, and is what the error message refers to as a "lobby". These are spun up or down on demand depending on population. I also suspect that housing and dungeons all end up sharing their own "lobbies" that contain multiple instances of each. For example there was a housing issue at one point which was caused by too many people using a particular house. Also when you fail to load into a queued dungeon straight away (and have to travel to player), it's probably because it had to spin up a new lobby to support it.

The cases where this bug might happen would be
1. The lobby is full and the server needs to create a new one for you to go into. This timed out or failed for whatever reason. You get booted. This one happens all the time during a busy keep fight in Cyrodiil!
2. The lobby doesn't exist at all and the server needs to create a new one for you to go into. Most likely for some really obscure delve. This timed out or failed for whatever reason. You get booted.

Cuddlypuff wrote: »

I get it a lot and I have a pretty good guess as to why it happens.

All of this sounds plausible. Add a "lobby" for initial login as well.

It all boils down to chronic sensitivity to/intolerance of glitchy/slow/intermittently lossy communications infrastructure ("glitchy/slow/lossy" pretty much sums up the internet as a whole, in practice). Not the way to go with large-scale distributed applications (which is what I do for a living, in real life). In fact, actively harmful.

Application design and implementation (including timeout/recovery mechanisms) need to accommodate these environmental constraints, and get tested at scale, before inflicting them on the customer.

ZOS_Bill wrote: »

To begin troubleshooting this login issue, we recommend the steps found in the link below.

I would respectfully request some (any?) evidence that ***Zenimax*** is engaged in "troubleshooting this login issue". Pushing generic procedural boilerplate on the customer that consists of "workarounds" that are manifestly ineffective... characteristically bureaucratic, but also harmful.

Realistically, the pathologies of a (regularly failing) application need to be addressed first, in this case to accommodate the idiosyncrasies of the application's operating environment, before any external action on the part of the customer can be expected to affect the behavior.

By definition, the concept of a "workaround" consists of customer adaptation to defective application behavior, but in this case Zenimax apparently expects the customer to work around the fundamental nature of the operating environment, and the application's selective but equally fundamental incompatibility with it. The dog won't hunt.