Check if an Application Update is in Progress Post-Upgrade in Okta Access Gateway

Starting in Okta Access Gateway (OAG) release 2024.11, the application update process executes on the Admin node after the node reboots post-upgrade. Administrators must verify if the update process is running before releasing the environment to users because users may encounter errors while accessing specific applications during the update. This update process only executes when upgrading from OAG version 2024.7 or earlier. During the upgrade, Okta Access Gateway generates the Applications need update. Scheduling update task on reboot log to detail the scheduled task.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Okta Access Gateway (OAG) Version 2024.11 or Newer

How does an administrator check whether an application update is in progress after an upgrade in Okta Access Gateway?

Access the management console shell on the admin node and execute the appropriate commands based on the Okta Access Gateway version to verify the update status.

1. Sign in to the management console shell on the admin node.
2. For versions 2024.11.2 and 2025.1, check the status by running the following command:

   ps -ef | grep updateAppsSSPUpgrade | grep -v grep

• • NOTE: When the script completes, the command does not generate any output, as shown in the following example.

    oag-local@admin;/home/oag-local# ps -ef | grep updateAppsSSPUpgrade | grep -v grep
    oag-local@admin;/home/oag-local#

3. For versions 2025.3 and later, run the command from step 2 or review the process logs located at /opt/oag/upgrades/current/Update_Apps.log.
   • NOTE: Once the process completes, the log file needs to be double-checked.
     

     grep CURL /opt/oag/upgrades/current/Update_Apps.log

      
     
     • If the nginx service does not come up, the error below will be seen. Users will be able to access the applications that were updated but as shown below it is only 1. The script needs to be ran again and please contact support.
       [0] oag-local@oag.support.lab;/home/oag-local# grep CURL test
       CURL POST: http://admin.service.spgw:8091/api/v1/app/f7da7b0d-048c-4381-955f-a84a7ae0db4c/3c8a1f2d-d45d-40d5-ae96-477df383c4d2 expected status code: 200, got: 500

        

   • Find the total number of apps:

     • ls -1 /opt/oag/configs/nginx/conf.d/icsgw_app_*.active.conf | wc -l

       Example output: 

       [0] oag-local@oag.support.lab;/home/oag-local# ls -1 /opt/oag/configs/nginx/conf.d/icsgw_app_*.active.conf | wc -l 15
   • Validate the number of apps updated
     • awk '/Updating IDP/{flag=1; next} flag{if($0 ~ /^#/) exit; print}' /opt/oag/upgrades/current/Update_Apps.log

       Example output (This failed and only 1 of the 15 applications were updated. Only the one application at this time will be accessible):

       [0] oag-local@oag.support.lab;/home/oag-local# awk '/Updating IDP/{flag=1; next} flag{if($0 ~ /^#/) exit; print}' test
Updating No Auth App being LB1
Updating local admin application
CURL POST: http://admin.service.spgw:8091/api/v1/app/f7da7b0d-048c-4381-955f-a84a7ae0db4c/3c8a1f2d-d45d-40d5-ae96-477df383c4d2 expected status code: 200, got: 500
RESPONSE:{"timestamp":"2026-10-14T16:34:05.227+00:00","status":500,"error":"Internal Server Error","path":"\/api\/v1\/app\/f7da7b0d-048c-4381-955f-a84a7ae0db4c\/3c8a1f2d-d45d-40d5-ae96-477df383c4d2"}

NOTE: The update process generates application update events and sends them to all worker nodes. If any node is unreachable or experiences latency, event processing takes additional time. Okta recommends testing the applications on the worker nodes approximately 10 to 15 minutes after the completion timestamp. Timings may vary depending on the number of applications or server connectivity issues.