Everybody with a Web site or service occasionally has to put up a maintenance page. Maybe you’re doing database maintenance that requires downtime, maybe you had a hardware failure, maybe Amazon Web Services is having some kind of outage.
You can either set up your application so that the page is displayed instead of what the customers expected to see, you can have a status page that shows whether the service is running, or you can redirect the user to the permanent URL where the maintenance page always lives. The latter approach is the wrong one. Here’s why.
Let’s say your service has a scheduled maintenance window that starts at midnight and ends at four in the morning. Your customers are most likely going to have to put up a maintenance page of their own and turn off the code that connects to your service while it’s down. Somebody is going to have to set their alarm, make sure the page is back up, and then reenable the service, update their own maintenance page, and so forth.
When said person gets up early in the morning, there’s a good chance they’ll go to the browser tab that’s displaying the state of your service and hit reload to see whether it’s back. If you have redirected them to a maintenance page that’s always around, they’re going to see that your site is down for maintenance even if it’s back up. At worst, they’ll assume your service is still down and not turn things back on at their end. At best, they’ll still have to finish waking up and actually investigate further.
Sure, putting a static page up somewhere and redirecting to it is easy, but it’s lazy and wrong. Don’t do it.
This message is brought to you by someone who had to set their alarm on a Sunday morning so that they could verify that a third party vendor had successfully completed scheduled maintenance and got confused after reloading the maintenance page in their browser.
February 11, 2013 at 1:04 am
I like a hybrid approach – redirect to a static page that has a 60 second reload to itself. When maintenance is complete, update the reload back to the homepage.
February 11, 2013 at 1:20 pm
As a sysadmin myself, I agree 100%. Redirecting the request is the worst thing you can do. If you’re a semantic HTTP devotee, there are status codes galore for appropriately handling the situation. If you’re just thinking about your users who will do exactly what you describe and reload the page every so often, it’s still the right solution. I’m guessing too often those redirects are done when the dev team and operations team don’t work together closely enough, and redirecting to a different URL is the quickest way to address the problem that can be implemented without involving the sysadmins.
February 11, 2013 at 6:47 pm
I’ve been using mod_rewrite to serve (not redirect to) a static file if it exists for any request. This also allows you to exempt certain IPs (or use custom headers) so ops can test real production before exposing to the whole world.