> I would ideally like to let the users know that there's a problem right now. For most services, there will not be - if the servers stay up, the users will ne

> I would ideally like to let the users know that there's a problem right now. For most services, there will not be - if the servers stay up, the users will never know or care that Oz is temporarily not behind the curtain. But sometimes it does matter. My husband runs a service where he needs manually process data and commit it every day that $foo is in session. If there's an emergency and he has to go offline, I can keep the servers online; if there's an emergency and we're both called away, there is a trusted 3rd party who does that job. But currently there is no other party who can process data. In that instance, we post a notice on the site saying that Friday commits will not be posted until Monday and apologise for the service interruption. I would, by the way, never make a public announcement that you are leaving the ship unmanned. That seems like a really poor security decision to me. YMMV. That's fine for a one-off, rare and unplanned instance. But you better believe that we have a much more robust plan for what to do if he gets hit by a bus. In that instance, there's a named and designated person in place to step up, an insurance policy to pay them (obviously with some delay), a secure and immediate process for transfer of passwords, and a 48 hour plan to execute. So really what I'm saying is that if you start with the worst case scenario and step back through that, I'm still not convinced that there are sudden departure scenarios you can't successfully address with forward planning.