Last Updated: February 25, 2016
· irregularshed

Organising a failover in IIS for when everything's gone wrong

I've been working on a site that's falling over a lot. A LOT. And we've been trying to fix it for days (the normal situation - runs fine on dev boxes and test boxes but the live boxes are all like "wtf?"). It's been very, very stressful for both my support team and our client (who are big enough to be a household name).

Due to the bank holiday weekend coming up (in England and, more importantly, Wales) we need to keep the site up whilst we're away, so I suggested (and the client agreed to) having a static HTML homepage derived from the live PHP output. It's only the homepage that's currently getting hit by rogue content and/or a rogue task, so the rest of the site needs to be accessed through the normal routing. To make things trickier, our client is on a full Windows stack whereas the skills within the company are far more attuned to Linux with Apache or Nginx, so I had to do some boning up on IIS rewriting.

Here's what I ended up with. It's pretty elegant considering what we're having to do, and it works really well...

<rule name="Failover" stopProcessing="true">
    <match url="^$" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
        <add input="{DOCUMENT_ROOT}/failover.html" matchType="IsFile" />
    <action type="Rewrite" url="/failover.html" />

What does it do? Well, if you're hitting the root of the site, and there's currently a file called failover.html in the root as well, it will use that for your homepage. If it's not there, it's business as usual. This goes ahead of the other rules that pass control over to our code.