If you run tableau in an enterprise environment you will likely have a lot of c level executives, global sales teams and more relying on tableau to be available outside of your local business hours. This means any maintenance needs to be planned and communications sent out to all stakeholders.

If reloading was an option then there wouldn't be downtime, and I wouldn't need to schedule a maintenance window for something as simple as updating an email address. The idea being that if there is a config error during a reload, the system just continues uninterrupted with the original config. If I have to stop the system completely in order to run the config sanity checks when it starts again, the potential for prolonged downtime is much greater.

Thanks for that perspective, I hadn't thought of that.

Would a system that did something like an internal cut-over be useful? e.g. try to start a whole new instance of the application, if it loads, then let it become the running application, if not, write an error log and shutdown?

It would still lose all the state associated with the previous instance, e.g. user sessions, but would avoid this specific issue.

I agree that it's pretty silly that things like email addresses need a restart, but I'm wondering in general how bad this pattern is.

That would work IMO, yes.

An interrupted session isn't a big deal if it's an infrequent occurrence and they can just login again.

I think an improved solution in this vein would be a tool that would let you sanity check the config before reloading.