JIRA returns an HTTP/500 status for several "normal" situations that don't necessarily represent an unrecoverable server error.  I've seen this behavior when JIRA is started with an incorrect license after restoring a configuration from another instance as well as various startup errors. 

Many web application firewalls (including F5's ASM) are configured out of box to block HTTP 500 errors as a security feature, preventing attackers from seeing stack traces or other useful debugging information.  These "normal" errors from JIRA don't contain stack traces or similar information.  When JIRA is in this state, it's necessary to access a JIRA instance directly, bypassing the WAF in order to resolve the situation.  That requires firewall changes, SSH tunnels, etc. as the the direct JIRA endpoints are not generally open for access when JIRA is fronted by a load balancer / WAF.

Initial configuration and error recovery would be easier if JIRA didn't throw a 500 error for these response pages where the entire cluster is affected.