Forums

What's the cleanest way to set up an offline page for emergencies or major updates? I have a basic 'offline for maintenance' page; how do I redirect traffic to it while I'm fixing or upgrading the site?

Hi there,
I know this isn't really an answer to your question, but would it be worth thinking about ways of avoiding having the "offline for maintenance" page at all? If you have a second, "dev" version of your site up and running, you could use that to test out your changes, and then when you're confident that everything works, you can update the code on your production site, and be happy that a quick restart will start showing your users the new version, with no need for any time when they see a broken version?

Hi Harry,

I am planning on having a staging site as well as production; I'm also hoping to minimise any changes that would require rebuilding the database. If, however, the site is hacked, I'd want to be able to take it offline in a controlled way while I figure out what's happened. With any luck I will never need to use an offline page, but I'd rather figure out how to do it before I need it.

in your case (wrt hacking), the best case would probably be to use a static configs in our webapps tab to serve an offline page to your customers.

Hi Conrad,

just so I'm sure I'm not missing anything: are you talking about (In an emergency) setting up a separate web app that serves the maintenance page and points to the domain name?

I was actually thinking of something like this:

You have your webapp setup for say abc.com. You create a folder say /home/textuality/emergency, which has a index.html in it. Then if there is ever an emergency, you could just set a static url to '/', and the directory to /home/textuality/emergency and reload your webapp. Then the home page of your webapp will go to the index.html. Of course, that doesn't actually stop people from going to the non root urls.

Alternatively, I guess you could setup a backup webapp (eg. just on textuality.pythonanywhere.com, or on anothersubdomain.yourwebsite.com), and if anything ever happens, you can just setup a redirect from your domain registrar so that www.yourwebsite.com etc gets redirected to anothersubdomain.yourwebsite.com. That is probably cleaner. For this backup webapp, if it's just a static html page, you could use the same procedure I described above.

Yes, that was my concern - that doesn't work for the non-root URLs. I expect direct links to pages to be a large part of the traffic this particular site gets.

Right. in that case, the second option will work (it will redirect all traffic to the new webapp)

Thanks Conrad. I hadn't thought of setting up a (302) redirect at the domain registrar, but that makes perfect sense. Here's hoping I never need to use it!

haha- should be pretty unlikely, unless you are doing anything super crazy/risky