This article explains how Admin UI reports the health check for the configured Okta Access Gateway (OAG) Load Balancer (LB) Hostnames. 

• Okta Access Gateway (OAG)

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.

 

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