I was wondering have you considered a watchdog script or service executing on the server itself monitoring the web server and server process?
Unless the issue is with the server itself or the network and not just the HTTPD service/daemon, then this might prove to be a better option. I don't know your specifics, so it is hard to say, but as previously mentioned a script doing a fetch on the router is going to cost quite a few write cycles on the NAND. The polling frequency is going to have a direct correlation on the write cycles. Of course this becomes a moot point or less of an issue if on board NAND isn't being used.
With a watchdog program executing on the web server, the program can take direct action on the server against the web process, recycling or downing the HTTPD process as needed. Potentially, a second HTTPD process either running on a different TCP port or on a different IP address (same server) could be used. Depending on available resources either a separate server or a virtual server could also be used. Depending on the setup a second HTTPD instance could then be tied to the same content or different content containing the message you described. If using separate IP addresses, the primary web server IP address could then be downed and a ping mechanism at the router could be used to trigger the fail over. Theoretically, you could forgo the second web instance and move the function of displaying the error message to the router. However, as great and flexible a device as Tik routers tend to be, IMO I think it is best if they are left to do what they were designed to do, network and route.
In my experience if the web site demands it, it is best to build in redundancy as there are many options available to do this and if there is a known issue with the HTTPD server failing, then it is best to fix it, though I suspect that this is not the case in this instance.