Okta Access Gateway Application Load Balancer Health Check Status

The Okta Access Gateway (OAG) Admin UI reports the health check status for configured load balancer hostnames by sending a request to the public domain of the application. The status reflects only the specific node that handles the request, which can result in an unknown health message if a certificate warning blocks the request. Verify the health check status using the Admin UI or a command-line script.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Okta Access Gateway (OAG)

How does the Okta Access Gateway Admin UI report health check statuses?

NOTE: If not on 2023.7.2, please upgrade to this version or higher.

The admin UI sends a health check request to the application's public domain, meaning it only shows the status of the node that handled the request. 

For example, if there are five backend hosts, all will report the status from one specific node (from the LB pool) unless there are sticky session issues in the LB. Once the sticky session timer expires, the LB will use a different node, and the status may change depending on the worker.

When editing the application configuration to view the status, opening the developer tools will reveal a call to the public domain labeled "health" that appears as follows:

https://noauth.support.lab/health-b51ce026-f27f-44af-b65d-1dd9c24f00ee

If there are multiple OAG nodes, a load balancer directs the traffic to different nodes. When the app config is opened in Admin UI, the request will be sent to the public domain of the application. The status will depend on which node the LB is sending traffic to. 
If the health check call does not get a response, then a yellow warning will be seen. For example, in the screenshot below, the health check call health-b51ce026-f27f-44af-b65d-1dd9c24f00ee did not receive a response, showing an unknown health message:
 

This issue can happen for multiple reasons. In this case, the browser was getting stuck on the certificate warning error. When browsing this site manually, the warning can be accepted, and the correct status will be shown.
 
The correct status was reflected after reloading the app edit page in the admin UI, which is unhealthy in this case. Since the warning was blocking the request, the status was showing as unknown before.
The incognito window in the middle is the screen shown after accepting the warning.

How is the health check status verified using a command-line script?

A curl command can be used to view the status of the resources at once. In the example below, there is an admin node and 2 worker nodes. Worker node 2 is failing the health check.

• Command:

  curl -v -k https://<ip/hostname>/health-b51ce026-f27f-44af-b65d-1dd9c24f00ee -H "HOST:<Public domain of the app>"

• Examples:
  Run once script

  sudo curl -k https://admin/health-b51ce026-f27f-44af-b65d-1dd9c24f00ee  -H "HOST:noauth.support.lab"
  [{"status":"healthy","hostname":"https:\/\/noauthtest.support.lab"}]
  
  sudo curl -k https://worker1/health-b51ce026-f27f-44af-b65d-1dd9c24f00ee  -H "HOST:noauth.support.lab"
  [{"status":"healthy","hostname":"https:\/\/noauthtest.support.lab"}]
  
  sudo curl -k https://worker2/health-b51ce026-f27f-44af-b65d-1dd9c24f00ee -H "HOST:noauth.support.lab"
  [{"hostname":"https:\/\/noauthtest.support.lab","status":"unhealthy"}]

• Scripts (Works on Mac or Linux):
  • Run once:

    for ip in <ip/hostname> <ip/hostname> <ip/hostname>; do echo "IP/HOSTNAME: " "$ip"; curl -k https://"$ip"/health-b51ce026-f27f-44af-b65d-1dd9c24f00ee -H "HOST:<Public domain of the app>"; done;

• • Constantly runs:

    while true; do for ip in <ip/hostname> <ip/hostname> <ip/hostname>; do echo "IP/HOSTNAME: " "$ip";echo "The time is : " $(date); curl -k https://"$ip"/health-b51ce026-f27f-44af-b65d-1dd9c24f00ee -H "HOST:<Public domain of the app>"; done; sleep 2;done