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.