If a failure, such as a crash or hang, occurs in an on-premises environment, the licensee usually keeps that information out of the public domain in order to protect their enterprise reputation. In the cloud, the situation is quite different. A crash or hang will affect a number of subscribers from multiple companies. The media are quickly reporting an outage, and the reputation loss is incurred by the Cloud vendor, not by the subscriber. In fact, subscribers even have an interest in the media helping put pressure on the Cloud vendor to stabilize the system and prevent recurrence. For that reason, the vendor needs to be prepared to offer clear, transparent updates in case of an outage incident. It's obviously too late to design customer communication channels once an incident has occurred. Whether by e-mail distribution, or a stream of web site postings, it is paramount to offer subscribers insight into the extent and expected duration of an outage. The first things customers look for in an outage are an account of affected users, and an estimated time of repair and restart. But a reliable estimate is often not available until the cause of the outage has been understood. In those first minutes (or heaven forbid, first hour) of an outage, another key piece of information to share is the extent of the outage. Subscribing companies will be receiving internal phone calls from their end users inquiring about the outage. They may learn from phone calls that they have users affected in locations A, B and D, but that doesn't tell them whether or not the system is available from locations C, E and F, nor even whether ALL users at locations A, B and D are affected. Rather than finding the answer by contacting end users, we need to be able to communicate in a timely manner what users are affected. For example, in the unlikely event a particular mail cluster, both the primary and secondary server, is incapacitated, we need to identify the subset of users served by that particular cluster and communicate who is affected. And sooner rather than later, we need to give an outlook for the time needed to repair and restart. We work hard to avoid ever getting into such a situation, but if we do, communication plans need to be ready in advance.