University of Alaska Outage History

Started Oct 02, 2026, 07:26 PM UTC· resolved Oct 05, 2026, 09:15 PM UTC

1. identified Oct 02, 2026, 07:26 PM UTC

   We have received reports that UAOnline is currently experiencing issues. The Identity Access Management team is aware and has identified the cause. A certificate issue is causing incorrect password errors for users who recently reset their credentials. We will be making updates at 3 hour intervals as they work towards a fix. Thank you for your patience during the resolution of this issue!

2. monitoring Oct 02, 2026, 09:42 PM UTC

   The IAM team has identified the issue with UAOnline and has implemented a fix, which is being monitored for effectiveness and stability. Thank you again for your patience during the resolution of this issue! You can expect further updates at the end of the business day (5:00PM) or as new information becomes available.

3. resolved Oct 05, 2026, 09:15 PM UTC

   The IAM team has resolved the issue with the UAOnline service, and confirmed the fix to be stable. The certificate update that caused the issue was reverted. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

Read the full incident report →

Started Sep 22, 2026, 12:09 AM UTC· resolved Sep 22, 2026, 04:09 PM UTC

1. investigating Sep 22, 2026, 12:09 AM UTC

   We have received reports that various websites and services are currently experiencing reliability issues. The OIT Networking and PAWS teams are investigating and suspect this to be a global-scale issue with a web host such as AWS. We will make updates as new information becomes available and at the end of the business day today (5:00PM AKDT). Thank you for your patience during the resolution of this issue!

2. monitoring Sep 22, 2026, 01:23 AM UTC

   Many services that were reported as impacted during this outage have been restored; we believe the issues may have been related to the US-EAST-1 incident that Amazon reported from 2:49 PM to 4:06 PM (https://health.aws.amazon.com/health/status). We will be monitoring service stability until the beginning of the business day tomorrow. Thank you again for your patience during the resolution of this issue! You can expect another update at 8:00AM AKDT.

3. resolved Sep 22, 2026, 04:09 PM UTC

   The services reported as affected have remained stable since the AWS fix yesterday evening, and we are considering this incident to be resolved. Please report any continued issues with UA sites and services to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

4. postmortem Oct 14, 2026, 10:28 PM UTC

   University Website and VPN External Accessibility Problem Impact Analysis Event Occurrence: 20260921 # Background University of Alaska provides Virtual Private Network \(VPN\) connectivity for university affiliated users located remotely and needing access to university network resources. Additionally the university hosts public facing websites intended to be accessed globally. These services, as well as others, are dependent upon connectivity between the university network and the wider internet, provided by our commodity internet service provider, Alaska Communications Systems \(ACS\). # Break Down of the Problem On 09/21/2026 at approximately 3:30pm, remote users outside of the university network reported issues loading university websites, and additionally reported interruption in connectivity to the university VPN. Technicians onsite reported that both VPN and web resources were accessible from within the university network. The OIT Telecommunications Services investigated and found that websites and VPN connectivity were working from within the university network, and that our network peering with ACS appeared to be up and receiving/advertising routes normally. An OIT technician from another workgroup on remote work and experiencing the connectivity issue reported that a traceroute from their home location to multiple university resources failed within the university's commodity internet service provider, Alaska Communications Systems \(ACS\) network prior to reaching the university network. OIT Telecommunications services at approximately 4:30pm received email communication from ACS confirming a network event within their network, followed by a subsequent email just prior to 5:30pm that the network event was resolved and services were stabilized. # Target State / Goal University of Alaska network connectivity to the internet at large should remain online at all times, providing remote access to UA network resources such as websites and VPN connectivity. ‌ # Root Cause Analysis This was determined to be caused by an event outside of the university network, within the commodity internet service provider \(ACS\) network, with ACS reporting upon resolution "_The network event impacting services has stabilized, and service restoration is complete._" While no point-to-point WAN circuits or commodity internet peerings were _directly_ affected, some network traffic transiting the ACS network via those commodity internet peerings was impacted during the provider event. # Develop Countermeasures Commodity internet service provider \(ACS\) resolved internal network event. # Implementation of Countermeasures OIT Telecommunications Services will reach out to service providers in the future as we become aware of potential issues impacting commodity internet connectivity. # Follow Up / Review ACS Provided email confirmation of internal network event resolution.

Read the full incident report →

Started Sep 21, 2026, 04:34 PM UTC· resolved Sep 21, 2026, 08:32 PM UTC

1. investigating Sep 21, 2026, 04:34 PM UTC

   We have received reports that alaska.edu and uaf.edu websites are currently experiencing issues. The OIT Platforms, Apps & Web Services (PAWS) team is currently investigating, and we will be making updates at 3-hour intervals. A current workaround is using a different browser than usual; Google Chrome has had high rates of success. Thank you for your patience during the resolution of this issue!

2. identified Sep 21, 2026, 08:04 PM UTC

   Alaska.edu and uaf.edu websites are currently experiencing issues. The OIT Platforms, Apps & Web Services (PAWS) team is working with Security and they have identified the issue. The certificate should be updated within the hour and status updated as soon as it's resolved. A current workaround is using a different browser than usual; Google Chrome has had high rates of success. Thank you for your patience during the resolution of this issue!

3. resolved Sep 21, 2026, 08:32 PM UTC

   PAWS has resolved the issue with the alaska.edu and uaf.edu sites, and confirmed the fix to be stable. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

4. postmortem Oct 07, 2026, 04:54 PM UTC

   University Website and VPN External Accessibility Problem Impact Analysis Event Occurrence: 20260921 # Background University of Alaska provides Virtual Private Network \(VPN\) connectivity for university affiliated users located remotely and needing access to university network resources. Additionally the university hosts public facing websites intended to be accessed globaly. These services, as well as others, are dependent upon connectivity between the university network and the wider internet, provided by our commodity internet service provider, Alaska Communications Systems \(ACS\). # Break Down of the Problem On 09/21/2026 at approximately 3:30pm, remote users outside of the university network reported issues loading university websites, and additionally reported interruption in connectivity to the university VPN. Technicians onsite reported that both VPN and web resources were accessible from within the university network. The OIT Telecommunications Services investigated and found that websites and VPN connectivity were working from within the university network, and that our network peering with ACS appeared to be up and recieving/advertising routes normally. An OIT technician from another workgroup on remote work and experiencing the connectivity issue reported that a traceroute from their home location to multiple university resources failed within the university's commodity internet service provider, Alaska Communications Systems \(ACS\) network prior to reaching the university network. OIT Telecommunications services at approximately 4:30pm received email communication from ACS confirming a network event within their network, followed by a subsequent email just prior to 5:30pm that the network event was resolved and services were stabilized. # Target State / Goal University of Alaska network connectivity to the internet at large should remain online at all times, providing remote access to UA network resources such as websites and VPN connectivity. # Root Cause Analysis This was determined to be caused by an event outside of the university network, within the commodity internet service provider \(ACS\) network, with ACS reporting upon resolution "_The network event impacting services has stabilized, and service restoration is complete._" While no point-to-point WAN circuits or commodity internet peerings were _directly_ affected, some network traffic transiting the ACS network via those commodity internet peerings was impacted during the provider event. # Develop Countermeasures Commodity internet service provider \(ACS\) resolved internal network event. # Implementation of Countermeasures OIT Telecommunications Services will reach out to service providers in the future as we become aware of potential issues impacting commodity internet connectivity. # Follow Up / Review ACS Provided email confirmation of internal network event resolution.

Read the full incident report →

Started Aug 28, 2026, 08:22 PM UTC· resolved Aug 28, 2026, 09:27 PM UTC

1. investigating Aug 28, 2026, 08:22 PM UTC

   We have received reports that Google Chat is currently experiencing issues. This is a vendor-side issue, and Google has indicated that their technicians are currently investigating. Live updates can be viewed on their Status Dashboard: https://www.google.com/appsstatus/dashboard/incidents/y2ufhCB886p7rveYNnko' Google Chat users are experiencing an issue where they receive notifications for new messages, but the actual messages fail to appear in their chat application unless the user refreshes their view. Users can refresh to see new messages. We will be making updates as new information becomes available and at 3-hour intervals. Thank you for your patience during the resolution of this issue!

2. resolved Aug 28, 2026, 09:27 PM UTC

   Google reports this issue has been resolved. Per their status dashboard: "The issue with Google Chat has been resolved for all affected users as of Friday, 2026-08-28 13:45 PDT. From preliminary analysis the issue was triggered due to a recent change which was rolled back to mitigate the impact. We thank you for your patience while we worked on resolving the issue." Thank you for your time as we followed this resolution!

3. postmortem Sep 09, 2026, 06:14 PM UTC

   This disruption was caused by a vendor outage and not related to University operations.

Read the full incident report →

Started Aug 25, 2026, 07:13 PM UTC· resolved Aug 28, 2026, 05:44 PM UTC

1. investigating Aug 25, 2026, 07:13 PM UTC

   We have received reports that Canvas is currently experiencing issues. The NTS Systems Engineering team is currently investigating, and we will be making updates at 2-hour intervals. Thank you for your patience during the resolution of this issue!

2. identified Aug 25, 2026, 07:58 PM UTC

   NTS Systems Engineering has provided a description of the issues currently recognized: "Some stacked Canvas courses are experiencing an issue. These courses were system generated as individuals or stacks based on the course information in Banner. The course shells in Canvas were then stacked or unstacked by an instructor or admin. The provisioning system that connects Banner data to Canvas ran a full re-provision August 24th to fix a number of enrollment discrepancies across Canvas. This fixed the enrollment issues, however it also undid any manual stack/unstack actions that had happened. For affected courses, instructors will see their courses unpublished, empty, and back to their original configuration. For students it will look like their course disappeared." We are currently recommending instructors pause any modifications to their affected courses, work with the Registrar to arrange the crosslist coding desired in Banner, then launch the course once it generates again in Canvas. Thank you again for your patience as we work towards a full resolution of the issues; we will continue to make updates as new information becomes available and at 2-hour intervals.

3. monitoring Aug 25, 2026, 11:42 PM UTC

   NTS System Engineering identified 378 potentially affected courses. All course materials are recoverable and instructors have a few options moving forward. NTS will work to recover any student submissions that came in before the provisioning. Instructors have 2 options: 1. Work with the system generated Canvas courses - These course shells can be populated with the content from the course from before the August 24th provisioning. Instructors can then publish and continue their courses. 2. Update the crosslist for your course in Banner - Delay your course and work with your department course scheduler to submit a proposal to change the crosslist structure in Banner to match what you want in Canvas. Once the change is complete and the new system generated Canvas course is available, it can be populated with the content from the course from before the August 24th provisioning. IF this is affecting your courses please email [email protected] with the CRNs of the courses and which option you are taking. NTS will only be able to help with restoring content. For instructors choosing option 2, you will need to contact your course scheduler. The Registrar is aware of this incident and is available to help schedulers submit the needed proposals.

4. monitoring Aug 26, 2026, 01:46 AM UTC

   The NTS Systems Engineering team is continuing to restore course content and remedy one-off issues. The two options available to instructors with affected Canvas classes are: 1. Work with the system generated Canvas courses - These course shells can be populated with the content from the course from before the August 24th provisioning. Instructors can then publish and continue their courses. 2. Update the crosslist for your course in Banner - Delay your course and work with your department course scheduler to submit a proposal to change the crosslist structure in Banner to match what you want in Canvas. Once the change is complete and the new system generated Canvas course is available, it can be populated with the content from the course from before the August 24th provisioning. If this is affecting your course(s), please email [email protected] with the CRNs of the courses and which option you would like to proceed with. NTS will only be able to help with restoring content, and can no longer manually cross-list or de-cross-list courses. For instructors choosing option 2, you will need to contact your course scheduler. The Registrar is aware of this incident and is available to help schedulers submit the needed proposals. Thank you again for your time as we work towards a full resolution! This is our final update for the business day, and reporting will begin again at the beginning of the day (8:00am AKDT).

5. monitoring Aug 26, 2026, 04:59 PM UTC

   Thank you for your patience as we work through the recent software issue that caused manually cross‑listed classes in Canvas to disconnect. NTS SE, OIT EAS, and UAF Registrar identified a work-around to allow manual cross-listing in Canvas. This revises previous guidance for instructors on how to proceed. Instructors can now opt to have their Canvas courses match their pre-incident configuration. Instructors are also able to do this reconfiguration themselves using the cross-listing tools in Canvas. If you are still experiencing problems, please submit a ticket to [email protected] and include the CRNs for the affected sections.

6. monitoring Aug 26, 2026, 07:10 PM UTC

   We have identified the configuration issue that caused manually cross‑listed classes in Canvas to disconnect. NTS SE, OIT EAS, and UAF Registrar implemented a fix to allow manual cross-listing in Canvas. We are monitoring the situation. If you are still experiencing problems and have not already submitted a help ticket, please submit a ticket to [email protected] and include the CRNs for the affected sections.

7. resolved Aug 28, 2026, 05:44 PM UTC

   Canvas courses remain able to be cross-listed by Canvas admins and instructors without issue, and we are considering this incident resolved at this time. If you are still experiencing problems or require your course content to be recovered and have not already submitted a help ticket, please do so by emailing [email protected] with a description of your issue/request and include the CRNs for the affected sections. Thank you so much for your patience as this issue was resolved!

8. postmortem Sep 22, 2026, 07:13 PM UTC

   Canvas LMS Degradation of Service Problem Impact Analysis Event Occurrence: 8/25/26 # Background The Canvas LMS platform provides web based digital classroom features to instructors and students. Courses, terms, and enrollments on the platform are managed through a direct connection to UAF’s SIS platform and Registrar processes. For most online courses and some in person courses, the associated Canvas course shell is the centralized location for all coursework, references, and grades. # Break Down of the Problem On 8/21/26 we received canvas support tickets from less than 5 users reporting that their course rosters were missing students or an instructor. Upon investigation, we found the configuration of the Canvas LMS to Banner SIS integration to have a timing issue. The integration, called ILP, does realtime updates of course enrollments when they meet certain criteria. The issue occurred because the enrollments in the course were changing before the course itself met the requirements to be monitored and updated by ILP. The fix for this issue was to reprovision the course. Reprovisioning treats the course information as ‘new’ regardless of if it had already been updated, making the Canvas course info match the Banner SIS course info. This solved the individual reported issues, but we needed to reprovision all of the courses, and continue to reprovision throughout the semester. Based on research in ILP forums, this is the solution for most institutions who encounter this issue. ‌ On 8/24/26 around 3 PM, we reprovisioned all UAF courses using the ‘bulk job’ tool in ILP. We then validated course enrollments from a few new tickets that had come in to ensure the fix had the intended effect. Courses that had been missing enrollments were corrected. ‌ On 8/24/26 at 5 PM we received reports of Canvas courses disappearing from students and instructors. Upon investigation, we found the courses affected were all cross-listed and the instructor had manually changed the system generated configuration by either cross-listing additional courses, or de-cross-listing courses. Instructors are able to do this in the Canvas platform with any courses they are listed as the instructor in. When we reprovisioned, the system changed the configurations of the Canvas courses to match Banner and this undid whatever the instructor had done. ‌ On 8/25/26 9 AM we began a degradation of service outage for Canvas as more Canvas service tickets came in. We communicated with all administrators advising them of the situation and to not cross-list courses in Canvas until we had more information. We posted an announcement to instructors and admins on the Canvas platform about the outage. We removed the permission for instructors in Canvas to be able to cross-list/de-cross-list their courses. We assessed the number of courses potentially impacted, and communicated with the instructors of record for each course. ‌ On 8/25/26 at 12 PM NTS-SE put out guidance to instructors to contact the Registrar if the system generated Canvas courses did not match what the instructor wanted. We discovered that instructors frequently cross-list courses across modalities in Canvas so they can manage all sections for a course in a single course shell. Canvas sections functionality allows them to do this without requiring them to expose cross-listed enrollments to each other. This is an important distinction between Canvas cross-listing and Registrar cross-listing: the term cross-listing/stacking for the Registrar means the enrollments are pooled together and it is expected that the students will be exposed to each other. Registrar policy prohibits cross-listing across modalities. This is a result of Faculty Senate concerns for anonymity in student course evaluations where a student could be identified by the modality of their response. Additional guidance was provided telling instructors to contact the NTS help desk for the recovery of any lost Canvas course content. These solutions did not work for many instructors who rely on the ability to cross-list in Canvas. ‌ On 8/25/26 at 4 PM NTS-SE, Registrar, and OIT-EAS working group met to review and test settings and options in ILP to get instructors out of work stoppage. The group identified a way to do reprovisioning without affecting cross-listed courses. The group identified the existing real-time update process that changes Canvas cross-list configurations. The group tested a fix to allow instructors to manually cross-list in Canvas, and then validated it in our test environment. The fix was to allow instructors to re-cross-list and/or submit NTS help desk tickets to have our teams re-cross-list and restore lost content. All future reprovisions will use a configuration that excludes cross-list information.The fix was communicated in an outage update and through a Canvas LMS platform announcement. The permissions for an instructor to be able to cross-list in Canvas were re-enabled. Administrators were informed that they could now cross-list for instructors. By 12 PM 8/26/26 The outage was moved to monitoring while we worked through tickets. By 9 AM 8/28/26 The outage was resolved. # Target State / Goal This issue changed the target state. Instructors should be able to manually cross-list or de-cross-list their course shells in Canvas, regardless of how the courses are coded in Banner. The cross-listing configuration should NOT be altered or set by the Banner ILP feed, nor should the cross-list status be watched nor updated from real-time monitoring. Active users should experience consistent access to the same Canvas course shell after the initial provisioning by the Banner ILP system except when manually changed by the instructor, or by an administrator.

Read the full incident report →

Started Aug 19, 2026, 11:57 PM UTC· resolved Aug 22, 2026, 12:16 AM UTC

1. monitoring Aug 19, 2026, 11:57 PM UTC

   Some AT&T mobile customers are currently unable to complete calls to campus phone numbers. This issue has been identified as originating with AT&T's network, not with our phone systems or services. We are monitoring the situation and will provide an update once calls are confirmed to be working normally again.

2. resolved Aug 22, 2026, 12:16 AM UTC

   We've had no further reports of issues calling the University, and the Fairbanks North Star Borough School District confirmed that their similar issues have been resolved. We are considering this outage resolved at this time; please call your campus IT service desk if you continue to have any issues contacting any UA campus by phone! Thanks so much for your time.

3. postmortem Sep 09, 2026, 06:10 PM UTC

   This disruption was caused by a vendor outage and not related to University operations.

Read the full incident report →

Started Aug 16, 2026, 08:54 PM UTC· resolved Aug 16, 2026, 11:56 PM UTC

1. identified Aug 16, 2026, 08:54 PM UTC

   We have received reports that card readers around the UAF campus are currently experiencing issues. The OIT PAWS team is aware and is actively working to recover the server that controls this system. We will be making updates at one-hour intervals as they work towards a fix. Building coordinators may be aware of alternative access methods and routes for particular rooms, but there is no widespread workaround at this time. Thank you for your patience during the resolution of this issue!

2. identified Aug 16, 2026, 10:01 PM UTC

   We are continuing to work on a fix for this issue.

3. identified Aug 16, 2026, 10:59 PM UTC

   We are continuing to work on a fix for this issue.

4. resolved Aug 16, 2026, 11:56 PM UTC

   OIT PAWS reports that the server for Lenel card swipe systems has been restarted successfully and is operational.

5. postmortem Aug 19, 2026, 09:25 PM UTC

   # **Root Cause Analysis – Argus Server Incident** ## **Executive Summary** The Argus server experienced a rapid loss of available space on the Windows C: drive. During investigation, PAWS identified significant disk activity occurring within the Lenel application log directory. Available disk space continued to decrease and eventually reached approximately 37 MB. PAWS cleanly shut down the server to prevent the operating system from reaching 0 available disk space and potentially causing additional system issues. PAWS expanded the C: drive and successfully returned the server to service. Following recovery, disk utilization stabilized and approximately 20 GB of free space remained available. PAWS is responsible for the underlying Windows server infrastructure but does not administer or support the Lenel application. The cause of the increased application-generated disk activity has not been determined and requires investigation by the application owner/vendor. ‌ ‌ ## **Incident Impact** The Argus server became unavailable during the incident and infrastructure recovery activities, resulting in an interruption to services dependent on the server. Reported impacts included on-campus door card reader functionality. ‌ ‌ ## **Timeline** **All times are Alaska Time.** **Approximately 11:04 AM** – PAWS was notified of an issue involving the Argus server and reported impacts to on-campus door card readers. The associated incident was TDX 991008. **Approximately 11:23 AM** – PAWS identified rapidly decreasing available space on the Windows C: drive. Resource Monitor showed significant write activity occurring within: `C:\ProgramData\Ln\logs` PAWS attempted to recover available disk capacity; however, C: utilization continued to increase. The C: drive eventually reached approximately **37 MB of available space**. PAWS cleanly shut down the VM to prevent the Windows system drive from reaching 0 available space and potentially causing additional operating system issues. PAWS performed the infrastructure work necessary to increase the capacity of the system drive. **Approximately 3:34 PM** – Infrastructure work was completed and the C: drive was expanded. The server was brought back online and PAWS verified normal server and disk operation. **Approximately 3:49 PM** – The server was reported operational. The following day, C: remained stable at approximately **19.9 GB free**, with no recurrence of the rapid disk consumption. ‌ ‌ ## **Root Cause** The immediate cause of the server outage was exhaustion of available capacity on the Windows C: drive. During the incident, PAWS observed significant disk write activity within the Lenel application log directory: `C:\ProgramData\Ln\logs` This activity rapidly consumed the remaining available capacity on the system drive. The underlying reason for the increased application-generated disk activity has **not been determined**. PAWS is responsible for administration of the underlying server infrastructure but does not administer, configure, or support the Lenel application. Determining why the application generated the increased disk activity requires investigation by the application owner/vendor and is outside the scope of this infrastructure RCA. ‌ ‌ ## **Contributing Factor** ### **Limited Available System Disk Capacity** The server did not have sufficient remaining C: drive capacity to absorb the unexpected increase in application-generated disk utilization. Available capacity eventually decreased to approximately **37 MB**, requiring PAWS to shut down the server to prevent Windows from reaching 0 available disk space. ‌ ‌ ## **Resolution** PAWS completed the following infrastructure recovery actions: * Investigated the rapidly decreasing C: drive capacity. * Identified the source directory associated with the increased disk activity. * Cleanly shut down the server before the system drive reached 0 available space. * Increased the capacity available to the Windows C: drive. * Returned the server to service. * Verified normal server and disk operation. * Continued monitoring disk utilization following recovery. Following recovery, the C: drive remained stable at approximately **19.9 GB free**. ‌ ‌ ## **Corrective and Preventative Actions** ### **Disk Capacity Monitoring** PAWS will review disk capacity monitoring and alert thresholds for the Argus server to provide sufficient notification when system drive capacity approaches critical levels. ### **Server Capacity** PAWS will continue monitoring C: drive utilization to verify that the additional capacity provides sufficient operating headroom under normal server conditions. ### **Application Investigation** The application owner/vendor will need to determine the cause of the unexpected increase in Lenel-generated disk activity and identify any application-level corrective actions that may be required. Application configuration, logging, retention, and application-level remediation are outside the scope of PAWS server administration. ‌ ‌ ## **Current Status** The Argus server is online and operational. The C: drive remained stable at approximately **19.9 GB free** during follow-up monitoring, with no recurrence of the rapid disk consumption observed during the incident. PAWS considers the **server infrastructure portion of the incident resolved**. The underlying cause of the Lenel application behavior remains undetermined and requires follow-up by the application owner/vendor.

Read the full incident report →

Started Aug 10, 2026, 07:02 PM UTC· resolved Aug 17, 2026, 04:53 PM UTC

1. investigating Aug 10, 2026, 07:02 PM UTC

   We have received reports that Banner is currently experiencing issues. The OIT EAS team is currently investigating, and we will be making updates at 1-hour intervals. A functioning workaround has been identified: open a private or incognito browser window to access Banner. If the site is still slow/not loading, close and open another new private or incognito window; it may take a few attempts, but once a reliable connection is made, you can continue to use that session until the issue is resolved! Thank you for your patience during the resolution of this issue!

2. monitoring Aug 10, 2026, 08:03 PM UTC

   The OIT EAS team has identified the issue with the Banner and has implemented a fix, which is being monitored for effectiveness and stability. Thank you again for your patience during the resolution of this issue! You can expect further updates at the end of the business day 5:00PM or as new information becomes available.

3. resolved Aug 17, 2026, 04:53 PM UTC

   The OIT EAS team has resolved the issue with the Banner, and confirmed the fix to be stable. Issue was resolved on Aug 10th. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

4. postmortem Aug 26, 2026, 06:27 PM UTC

   Banner Employee Service Unresponsive Problem Impact Analysis Event Occurrence: August 10, 2026 10:30am to 10:53am # Background The Banner Employee Self Service application is the main service that employees submit timesheets, view their leave balances, and similar items related to their employment across the University of Alaska System. The vendor Ellucian hosts the University Banner and Banner Self Service instances and is responsible for ensuring their availability through monitoring and corrective actions. # Break Down of the Problem At approximately 10:35am the UAF NTS Service Desk reached out to Banner team in Slack to inform them about reports of extreme slowness in Banner. A brief review revealed that only the Employee Self Service module was encountering issues. The Service Desk recommended a work around of trying an incognito browser, which worked for some. The EAS team reached out to Ellucian and created a P1 ticket. The service began functioning again as expected at approximately 10:53am. # Target State / Goal All components of Banner and Banner Self Service should be available with the expectations of the daily maintenance window and other scheduled outage times. # Root Cause Analysis The Ellucian cloud team which was engaged during restoration shared the following related to this event. Review of their monitoring showed that a performance degradation started at 10:42am and became fully unavailable at 10:50am. The automation related to the containers completed a successful start up at 10:53am and by 10:57am Employee Self Service fully stabilized. Ellucian did not evaluate any further related to cause of the outage. The EAS team is aware of a product defect in the Banner Employee Self Service software that was shown to cause this sort of event, first experienced in March and April of this year related to a product defect that has yet to be corrected in production, but is scheduled for application. # Develop Countermeasures To resolve this for the future, we expect that applying the recent defect resolution fix will correct this issue. # Implementation of Countermeasures September 12-13, 2026: Deploy Banner related upgrades that resolve the identified defects. # Follow Up / Review September 14, 2026: Validate upgrades for resolution were deployed.

Read the full incident report →

Started Aug 03, 2026, 04:55 PM UTC· resolved Aug 26, 2026, 08:10 PM UTC

1. investigating Aug 03, 2026, 04:55 PM UTC

   We have received reports that the Iru web login option is currently experiencing issues. The NTS Technology Support Services team is currently investigating, and we will be making updates at 3 hour intervals. Switching to local login should allow you to log into your Mac. Thank you for your patience during the resolution of this issue!

2. investigating Aug 03, 2026, 05:25 PM UTC

   The NTS Technology Support Services (TSS) team is currently investigating the cause of this issue. If unable to log into your UA Mac, they try switching to Local login. To switch to local login: 1. Click the profile icon (the person inside a circle) in the upper-right corner of the screen. 2. Select Switch to Local Login. 3. Enter your University login credentials in the username and password fields that appear near the bottom center of the screen. 4. Click Sign In to log in. If you are still unable to log in, please contact your local IT Help Desk for further assistance. Thank you for your continued patience as we work towards a full resolution; we will make further updates at 3 hour intervals and as new information becomes available.

3. investigating Aug 03, 2026, 06:02 PM UTC

   NTS TSS team is currently investigating the cause of this issues. The Iru prompt to sync your passwords is safe to ignore as best that you are able while we investigate why it is being prompted. If unable to log into your UA Mac, they try switching to Local login. To switch to local login: 1. Click the profile icon (the person inside a circle) in the upper-right corner of the screen. 2. Select Switch to Local Login. 3. Enter your University login credentials in the username and password fields that appear near the bottom center of the screen. 4. Click Sign In to log in. If you are still unable to log in, please contact your local IT Help Desk for further assistance. Thank you for your continued patience as we work towards a full resolution; we will make further updates at 3 hour intervals and as new information becomes available.

4. investigating Aug 03, 2026, 07:44 PM UTC

   NTS TSS team is continuing to investigate the cause of this issues. There are no further updates at this time. The Iru prompt to sync your passwords is safe to ignore as best that you are able while we investigate why it is being prompted. If unable to log into your UA Mac, they try switching to Local login. To switch to local login: 1. Click the profile icon (the person inside a circle) in the upper-right corner of the screen. 2. Select Switch to Local Login. 3. Enter your University login credentials in the username and password fields that appear near the bottom center of the screen. 4. Click Sign In to log in. If you are still unable to log in, please contact your local IT Help Desk for further assistance. Thank you for your continued patience as we work towards a full resolution; we will make further updates at 1 hour intervals and as new information becomes available.

5. monitoring Aug 03, 2026, 10:35 PM UTC

   We have resolved a recent issue caused by an unexpected change with Duo authentication that impacted managed macOS computer logins across campus. If you use a university-managed Mac, your login experience is now restored to normal operations. However, the first time you log back into your computer following this fix, you may see one or two additional Duo authentication prompts. When signing into your managed Mac for the first time today: 1. Enter your usual account credentials at the primary macOS login screen. 2. Complete the Duo prompt(s): You may be prompted to authenticate through Duo an extra time as system permissions refresh and re-sync with your account. 3. Approve the request on your Duo mobile app, hardware token, or via your preferred MFA method as normal. 4. Select Next at the Let’s keep your account secure prompt. 5. Select Next at the Set up a sign-in method prompt. If you continue to encounter login errors, repeated prompts to sync passwords on login, or any other issues logging into your Mac, please reach out to your campus IT Helpdesk.

6. resolved Aug 26, 2026, 08:10 PM UTC

   This incident has been resolved.

7. postmortem Aug 26, 2026, 08:11 PM UTC

   IRU Authentication Outage Problem Impact Analysis Event Occurrence: 20260803 # Background The IRU authentication service provides user authentication capabilities for managed macOS devices and web-based access through Kandji Passport. The service relies on integration between Kandji Passport, Microsoft Entra ID, Conditional Access policies, and Duo MFA to provide secure authentication for users. # Break Down of the Problem On August 3, 2026, users experienced authentication issues when attempting to access IRU services. The issue affected users attempting to authenticate through Kandji Passport Web Login and impacted the ability to complete the login process. The issue was investigated through Entra ID sign-in logs, Conditional Access policies, Duo MFA authentication flow, and Kandji Passport authentication services. # Target State / Goal A functional authentication into IRU-managed macOS devices. # Root Cause Analysis ‌ Changes to Microsoft’s Conditional Access methods, effective as of Jun 15, 2026: * [https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-enforcement-resource-exclusions](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-enforcement-resource-exclusions) * [https://techcommunity.microsoft.com/blog/microsoft-entra-blog/upcoming-conditional-access-change-improved-enforcement-for-policies-with-resour/4488925](https://techcommunity.microsoft.com/blog/microsoft-entra-blog/upcoming-conditional-access-change-improved-enforcement-for-policies-with-resour/4488925) The changes outlined above now require DUO to be set as the default login method on a user’s account in M365. # Develop Countermeasures Immediate countermeasure developed by adding users to Entra group that enabled the newer DUO authentication method. # Implementation of Countermeasures IT staff completed a change that added all users to receive this fix. # Follow Up / Review Regularly review progress of long term solution implementation.

Read the full incident report →

Started Jul 24, 2026, 05:46 PM UTC· resolved Jul 25, 2026, 01:06 AM UTC

1. identified Jul 24, 2026, 05:46 PM UTC

   Access to vdi.alaska.edu is unavailable, but the cause of the outage has been identified. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able to access or use Virtual Machines from that address until the issue has been resolved.

2. identified Jul 24, 2026, 06:55 PM UTC

   UA has identified the issue with accessing vdi.alaska.edu and is working to resolve it. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able use Virtual Machines from that address. Thank you for your patience during the resolution of this issue. Please expect an update at 11:50 AM and hourly updates after.

3. identified Jul 24, 2026, 08:12 PM UTC

   UA has identified the issue with accessing vdi.alaska.edu and is working to resolve it. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able use Virtual Machines from that address. Thank you for your patience during the resolution of this issue. Please expect an update at 12:50 AM and hourly updates after.

4. identified Jul 24, 2026, 08:55 PM UTC

   UA has identified the issue with accessing vdi.alaska.edu and is working to resolve it. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able use Virtual Machines from that address. Thank you for your patience during the resolution of this issue. Please expect an update at 1:50 PM and hourly updates after.

5. identified Jul 24, 2026, 10:35 PM UTC

   UA has identified the issue with accessing vdi.alaska.edu and is working to resolve it. Any desktop access through vdi.alaska.edu, and possibly the thick client, will not be able use Virtual Machines from that address. Thank you for your patience during the resolution of this issue. Please expect an update at 5:00 PM.

6. monitoring Jul 25, 2026, 12:03 AM UTC

   UA has resolved the issue with the vdi.alaska.edu and confirmed the fix to be stable. This will be placed in monitoring until end of business at 5:00 PM. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

7. resolved Jul 25, 2026, 01:06 AM UTC

   UA has resolved the issue with the vdi.alaska.edu and confirmed the fix to be stable. Please report any continued issues with this service to your campus's IT helpdesk and thank you again for your patience during the resolution of this issue!

8. postmortem Aug 19, 2026, 09:26 PM UTC

   [vdi.alaska.edu](http://vdi.alaska.edu) access disruption. ‌ Expired Unified Access Gateway Certificates. Date Time:07/23/2026 4:00 PM. # Background [vdi.alaska.edu](http://vdi.alaska.edu) provides user access to the VMware/Omnissa Horizon VDI environment. ‌ Both Unified Access Gateway appliances \(exist on the VXrail platform\) provide the external access layer for users who want to access their VDI both on campus or remotely. ‌ # Break Down of the Problem Both certificates on each UAG expired on July 23, 3:59 PM, 2026. ‌ The problem was noticed Friday morning July 24th around 8:30 am, when users reported they could not access their “My Desktop” VDI environments when resolving to [vdi.alaska.edu](http://vdi.alaska.edu) ‌ ‌ When a user tried to resolve to [vdi.alaska.edu](http://vdi.alaska.edu) through their browser, they received a “Your connection is not private” notice and then would be blocked from reaching the [vdi.alaska.edu](http://vdi.alaska.edu) Horizon page at all. ‌ Actions taken to restore service: Requested renewal certificate from PAWS. This cert contained the primary domain name, [vdi.alaska.edu](http://vdi.alaska.edu) but also included the alternate names \(both UAG names\) [fbk-uag1.apps.ad.alaska.edu](http://fbk-uag1.apps.ad.alaska.edu) [fbk-uag2.apps.ad.alaska.edu](http://fbk-uag2.apps.ad.alaska.edu) [fbk-uag1.io.apps.ad.alaska.edu](http://fbk-uaf1.io.alaska.edu) [fbk-uag2.io.alaska.edu](http://fbk-uag2.io.alaska.edu) ‌ ‌ Duration of outage and time that service was restored: Thursday July 23rd 4:00 pm - Friday the 24th 2:00 pm. ‌ ‌ ‌ # Target State / Goal ‌ Both UAG’s should continuously present valid, trusted certificates and external and internal VDI access ‌ # Root Cause Analysis # Both UAG appliances were presenting expired TLS certificates. TSS received a list of VXrail server appliances that had estimated times of when their certificates were expiring. Both UAG appliances were not in this list so we were unable to dictate when their certificates were going to expire. # Develop Countermeasures I created a master certificate spreadsheet that now contains both UAG’s certificate information to include expiration dates. I’m sharing it with our TSS team leads so we can continue to monitor expected certificate expirations in the future. Requested access to Certinext service for future certificate renewals. ‌ Schedule for the implementation: The above should allow us to request and implement the certs before they expire on both UAG’s before they expire. # Follow Up / Review Verify certificate expiration dates on both UAG’s by monitoring the master certificate spreadsheet. Put in a request to PAWS to renew the certificate, plan a brief CAB outage, apply the certificate to both UAG’s and then confirm renewal was successful and access occurs

Read the full incident report →

Started May 29, 2026, 04:26 PM UTC· resolved May 30, 2026, 01:01 AM UTC

1. investigating May 29, 2026, 04:26 PM UTC

   We have received reports that Banner Admin is currently experiencing issues at login. A workaround has been identified for some users: attempt to load https://banner.alaska.edu/ in new incognito/private browser windows until the login screen successfully loads. The OIT Enterprise Applications Services (EAS) team is currently investigating, and we will be making updates at 1-hour intervals. Thank you for your patience during the resolution of this issue!

2. monitoring May 29, 2026, 05:01 PM UTC

   Ellucian, the vendor for Banner, has identified the issue and implemented a fix, which is being monitored for effectiveness and stability. Thank you again for your patience during the resolution of this issue! You can expect another update at the end of the business day (5:00PM) or if new information becomes available.

3. resolved May 30, 2026, 01:01 AM UTC

   The fix applied to Banner Admin has remained stable, and we are considering the outage resolved at this time. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during its resolution!

4. postmortem Jul 01, 2026, 06:10 PM UTC

   UAOnline and Banner Admin Login Issue Problem Impact Analysis Event Occurrence: May 28, 2026 4am to 11:15am, May 29, 2026 4am to 9am # Background UAOnline is the self service portal for Ellucian Banner used as the university’s Enterprise Resource Planning \(ERP\) system. These systems are hosted in Ellucian cloud and require period maintenance including security certificate updates for trust between UA and Ellucian systems. The Banner software periodically has system defects that are addressed by daily application restarts. # Break Down of the Problem ‌ On May 28th at 6:56am, a notice was sent to the Banner team through slack that a person was receiving an error when attempting to access the Employee Dashboard. The vendor Ellucian was notified of the event and identified the issue and implemented a work around. On May 29th at 8:11am, the same issue was reported through the Banner team slack channel for Banner Admin. The same ticket opened the prior day was used to report the issue and they used the same work around from the day before to restore service prior to 9:00am. # Target State / Goal Banner self service \(Employee Dashboard\) and Banner Admin services should be available to customers 24/7 except during pre-defined maintenance windows. # Root Cause Analysis ‌ Ellucian in preparation for an upcoming security certificate renewal staged changes in the production environment for the following weekend’s activity. There were mitigations in place due to Banner product defects that would restart Banner service instances daily at 4am. The restart process triggered the inclusion of these new certificates, causing a mismatch of certificates that prevented Single Sign On services from connecting for both Banner admin and the employee self service module. # Develop Countermeasures ‌ * Complete the implementation of the new certificates. * Provide feedback to the vendor to ensure their staff are properly equipped to avoid this in the future. # Implementation of Countermeasures May 30, 7:00 PM: Complete implementation of certificate change over for the whole system. June 2, 11:00AM: Convey feedback to vendor on how they need to change. # Follow Up / Review May 30-31: Validate certificate replacement is working for all systems. June 2: Vendor notified and RCA was provided by vendor, confirming what occurred.

Read the full incident report →

Started May 28, 2026, 04:02 PM UTC· resolved May 29, 2026, 01:49 AM UTC

1. investigating May 28, 2026, 04:02 PM UTC

   We have received reports that forms in Banner admin are not loading, and UAOnline's Employee login is experiencing authentication issues. The OIT EAS team is currently reaching out to the vendor, and we will be making updates at 30-minute intervals. Thank you for your patience during the resolution of this issue!

2. investigating May 28, 2026, 04:36 PM UTC

   OIT EAS has contacted the vendor for Banner and are monitoring their communication channels for updates. We will continue to make updates as new information becomes available and at 30-minute intervals. Thank you again for your time and patience while we work towards a resolution!

3. investigating May 28, 2026, 05:06 PM UTC

   OIT EAS reports the vendor's technicians are engaged and working on both Banner/UAOnline issues experienced. We will continue to make updates as new information becomes available and at 30-minute intervals. Thank you again for your time and patience while we work towards a resolution!

4. investigating May 28, 2026, 05:34 PM UTC

   The issue is continuing to be worked, and there is no new information available at this time. We will continue to make updates as new information becomes available and at 30-minute intervals. Thank you again for your time and patience while we work towards a resolution!

5. investigating May 28, 2026, 06:01 PM UTC

   The issue is continuing to be worked, and there is no new information available at this time. We will continue to make updates as new information becomes available and at 30-minute intervals. Thank you again for your time and patience while we work towards a resolution!

6. investigating May 28, 2026, 06:32 PM UTC

   The issue is continuing to be worked, and there is no new information available at this time. We will continue to make updates as new information becomes available and at 30-minute intervals. Thank you again for your time and patience while we work towards a resolution!

7. investigating May 28, 2026, 07:03 PM UTC

   The issue is continuing to be worked, and there is no new information available at this time. We will continue to make updates as new information becomes available and at 30-minute intervals. Thank you again for your time and patience while we work towards a resolution!

8. monitoring May 28, 2026, 07:16 PM UTC

   Ellucian, the vendor for Banner, has identified the issue and implemented a fix, which is being monitored for effectiveness and stability. Thank you again for your patience during the resolution of this issue! You can expect further updates at the end of the business day (5:00PM) or as new information becomes available.

9. resolved May 29, 2026, 01:49 AM UTC

   The fix applied to Banner Admin and the UAOnline Employee Dashboard has remained stable, and we are considering the outage resolved at this time. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

10. postmortem Jul 01, 2026, 06:03 PM UTC

    UAOnline and Banner Admin Login Issue Problem Impact Analysis Event Occurrence: May 28, 2026 4am to 11:15am, May 29, 2026 4am to 9am # Background UAOnline is the self service portal for Ellucian Banner used as the university’s Enterprise Resource Planning \(ERP\) system. These systems are hosted in Ellucian cloud and require period maintenance including security certificate updates for trust between UA and Ellucian systems. The Banner software periodically has system defects that are addressed by daily application restarts. # Break Down of the Problem ‌ On May 28th at 6:56am, a notice was sent to the Banner team through slack that a person was receiving an error when attempting to access the Employee Dashboard. The vendor Ellucian was notified of the event and identified the issue and implemented a work around. On May 29th at 8:11am, the same issue was reported through the Banner team slack channel for Banner Admin. The same ticket opened the prior day was used to report the issue and they used the same work around from the day before to restore service prior to 9:00am. # Target State / Goal Banner self service \(Employee Dashboard\) and Banner Admin services should be available to customers 24/7 except during pre-defined maintenance windows. # Root Cause Analysis ‌ Ellucian in preparation for an upcoming security certificate renewal staged changes in the production environment for the following weekend’s activity. There were mitigations in place due to Banner product defects that would restart Banner service instances daily at 4am. The restart process triggered the inclusion of these new certificates, causing a mismatch of certificates that prevented Single Sign On services from connecting for both Banner admin and the employee self service module. # Develop Countermeasures ‌ * Complete the implementation of the new certificates. * Provide feedback to the vendor to ensure their staff are properly equipped to avoid this in the future. # Implementation of Countermeasures May 30, 7:00 PM: Complete implementation of certificate change over for the whole system. June 2, 11:00AM: Convey feedback to vendor on how they need to change. # Follow Up / Review May 30-31: Validate certificate replacement is working for all systems. June 2: Vendor notified and RCA was provided by vendor, confirming what occurred.

Read the full incident report →

Started May 16, 2026, 04:20 PM UTC· resolved Jun 01, 2026, 05:05 PM UTC

1. investigating May 16, 2026, 04:20 PM UTC

   There is an Active Directory issue that is preventing users from logging into certain systems. The PAWS/Networking/Security teams are actively troubleshooting and investigating the issue.

2. investigating May 16, 2026, 05:30 PM UTC

   An Active Directory issue is currently affecting UAF Servers and Services. The PAWS, Networking, and Security teams are actively troubleshooting and investigating the issue. If you are a user logging into a server remotely using VDI, VPN, or other services, such as WiFi, that use your UA AD credentials, they may show as invalid. The cause is still being identified and the scope of the affected systems and services are still being assessed.

3. investigating May 16, 2026, 05:49 PM UTC

   An Active Directory issue is currently affecting UAF Servers and Services. The PAWS, Networking, and Security teams are actively troubleshooting and investigating the issue. If you are a user logging into a server remotely using VDI, VPN, or other services, such as WiFi, that use your UA AD credentials, they may show as invalid. The cause is still being identified and the scope of the affected systems and services are still being assessed.

4. investigating May 16, 2026, 06:24 PM UTC

   An Active Directory issue is currently affecting UAF Servers and Services. The PAWS, Networking, and Security teams are actively troubleshooting and investigating the issue. A possible cause is being investigated and an update will be sent out as soon as it's identified. If you are a user logging into a server remotely using VDI, VPN, or other services, such as WiFi, that use your UA AD credentials, they may show as invalid. The cause is still being identified and the scope of the affected systems and services are still being assessed.

5. investigating May 16, 2026, 07:23 PM UTC

   There are no new updates as of 11:21AM. Reporting will continue until the end of day at 5PM. An Active Directory issue is currently affecting UAF Servers and Services. The PAWS, Networking, and Security teams are actively troubleshooting and investigating the issue. A possible cause is being investigated and an update will be sent out as soon as it's identified. If you are a user logging into a server remotely using VDI, VPN, or other services, such as WiFi, that use your UA AD credentials, they may show as invalid. The cause is still being identified and the scope of the affected systems and services are still being assessed.

6. investigating May 16, 2026, 08:21 PM UTC

   There are no new updates as of 12:20PM. The issue is continuing to be investigated and reporting will continue until the end of day at 5PM. An Active Directory issue is currently affecting UAF Servers and Services. The PAWS, Networking, and Security teams are actively troubleshooting and investigating the issue. A possible cause is being investigated and an update will be sent out as soon as it's identified. If you are a user logging into a server remotely using VDI, VPN, or other services, such as WiFi, that use your UA AD credentials, they may show as invalid. The cause is still being identified and the scope of the affected systems and services are still being assessed.

7. investigating May 16, 2026, 09:31 PM UTC

   There are no new updates as of 1:30PM. The issue is continuing to be investigated and reporting will continue until the end of day at 5PM. An Active Directory issue is currently affecting UAF Servers and Services. The PAWS, Networking, and Security teams are actively troubleshooting and investigating the issue. A possible cause is being investigated and an update will be sent out as soon as it's identified. If you are a user logging into a server remotely using VDI, VPN, or other services, such as WiFi, that use your UA AD credentials, they may show as invalid. The cause is still being identified and the scope of the affected systems and services are still being assessed.

8. investigating May 16, 2026, 10:55 PM UTC

   Update (2:45 PM): The Authentication Issues affecting UAF servers and services is still under investigation. The PAWS, Networking, and Security teams are actively troubleshooting a potential cause. User Impact: The UAF Devices Portal, Wi-Fi, Remote logins via VDI, VPN, or other services using UA AD credentials may fail or show as invalid. Further updates will be shared as soon as a cause is identified, with continuous reporting through 5:00 PM.

9. investigating May 16, 2026, 11:34 PM UTC

   Update (3:33 PM): The Authentication Issues affecting UAF servers and services is still under investigation. The PAWS, Networking, and Security teams are actively troubleshooting a potential cause. User Impact: The UAF Devices Portal, Wi-Fi, Remote logins via VDI, VPN, or other services using UA AD credentials may fail or show as invalid. Further updates will be shared as soon as a cause is identified, with continuous reporting through 5:00 PM.

10. investigating May 17, 2026, 07:00 AM UTC

    The Authentication Issues affecting UAF servers and services is still under investigation. The PAWS, Networking, and Security teams will continue remediation efforts tomorrow morning at 8:00 AM. User Impact: The UAF Devices Portal, Wi-Fi, Remote logins via VDI, VPN, or other services using UA AD credentials may fail or show as invalid. Further updates will be posted here tomorrow morning. Thank you for your patience.

11. investigating May 17, 2026, 03:52 PM UTC

    The Authentication Issues affecting UAF servers and services are still under investigation. The PAWS, Networking, and Security teams will continue remediation efforts this morning at 8:00 AM. User Impact: The UAF Devices Portal, Wi-Fi, Remote logins via VDI, VPN, or other services using UA AD credentials may fail or show as invalid. Further updates will be posted here later today. Thank you for your patience.

12. investigating May 17, 2026, 09:03 PM UTC

    As of 1PM on Sunday, May 17th, our teams are still actively troubleshooting the authentication issues. Teams are working with Cisco and Microsoft to investigate the cause. We will post more information as soon as it's available. User Impact: The UAF Devices Portal, Wi-Fi, Remote logins via VDI, VPN, or other services using UA AD credentials may fail or show as invalid. Further updates will be posted here later today. Thank you for your patience while we find a solution.

13. identified May 18, 2026, 01:19 AM UTC

    As of 5PM on Sunday, May 17th, our teams are still actively troubleshooting the authentication issues. Teams are working with Cisco and Microsoft to investigate the cause. We will post more information as soon as it's available. At this time, university Wi-Fi, VPN and VDI services have been restored. User Impact: The UAF Devices Portal or other services using UA AD credentials may fail or show as invalid. Our next scheduled update is 11PM. Thank you for your patience while we find a solution.

14. identified May 18, 2026, 07:03 AM UTC

    As of 11PM on Sunday, May 17th, our teams are still actively troubleshooting the authentication issues. Teams are working with Cisco and Microsoft to investigate the cause. The next update will be tomorrow at 7AM. At this time, university Wi-Fi, VPN and VDI services have been restored. User Impact: The UAF Devices Portal or other services using UA AD credentials may fail or show as invalid.

15. identified May 18, 2026, 03:03 PM UTC

    As of 7AM on Monday, May 18th, the current fixes in place are holding steady. Our teams are working with Cisco and Microsoft on troubleshooting the authentication issues. The next update will be later this morning at 8AM. At this time, university Wi-Fi, VPN and VDI services have been restored. User Impact: The UAF Devices Portal or other services using UA AD credentials may fail or show as invalid.

16. identified May 18, 2026, 04:14 PM UTC

    As of 8AM on Monday, May 18th, the current fixes in place are holding steady. Our teams are working with Cisco and Microsoft on troubleshooting the authentication issues. More information will be available after the 9AM meeting with diagnostic teams from this weekend. The next update will be later this morning at 9AM. At this time, university Wi-Fi, UAF Devices Portal, VPN and VDI services have been restored. *You may have to clear your cache or use an incognito/private browsing window access the UAF Devices Portal. For help with this, call the NTS Service Desk. User Impact: Some services using UA AD credentials may still fail or show as invalid.

17. identified May 18, 2026, 05:14 PM UTC

    As of 9AM on Monday, May 18th, the current fixes in place are holding steady. Our teams are working with Cisco and Microsoft on troubleshooting the authentication issues. More information will be available after meeting with diagnostic teams from this weekend. The next update will be later this morning at 10AM. At this time, university Wi-Fi, UAF Devices Portal, VPN and VDI services have been restored. *You may have to clear your cache or use an incognito/private browsing window access the UAF Devices Portal. For help with this, call the NTS Service Desk. User Impact: Some services using UA AD credentials may still fail or show as invalid.

18. identified May 18, 2026, 06:18 PM UTC

    As of 10AM on Monday, May 18th, the current fixes in place are holding steady. Our teams are working with Cisco and Microsoft on troubleshooting the authentication issues. More information will be available after meeting with diagnostic teams from this weekend. The next update will be later this morning at 11AM. At this time, university Wi-Fi, UAF Devices Portal, VPN and VDI services have been restored. *You may have to clear your cache or use an incognito/private browsing window access the UAF Devices Portal. For help with this, call the NTS Service Desk. User Impact: Some services using UA AD credentials may still fail or show as invalid.

19. identified May 18, 2026, 07:02 PM UTC

    As of 11AM on Monday, May 18th, the current fixes in place are holding steady. Our teams are working with Cisco and Microsoft on troubleshooting the authentication issues. More information will be posted as soon as it's available. The next update will be later today at 12PM. At this time, university Wi-Fi, UAF Devices Portal, VPN and VDI services have been restored. *You may have to clear your cache or use an incognito/private browsing window access the UAF Devices Portal. For help with this, call the NTS Service Desk. User Impact: Some services using UA AD credentials may still fail or show as invalid.

20. identified May 18, 2026, 08:17 PM UTC

    As of 12PM on Monday, May 18th, the current fixes in place are still holding steady. Our teams are continuing to work with Cisco and Microsoft on troubleshooting the authentication issues. More information will be posted as soon as it's available. The next update will be later today at 1PM. At this time, university Wi-Fi, UAF Devices Portal, VPN and VDI services have been restored. *You may have to clear your cache or use an incognito/private browsing window access the UAF Devices Portal. For help with this, call the NTS Service Desk. User Impact: Some services using UA AD credentials may still fail or show as invalid.

21. monitoring May 18, 2026, 09:36 PM UTC

    As of 1PM on Monday, May 18th, while we are in monitoring mode, all impacted systems have been restored and continue to be stable. More information will be posted as soon as it's available. The next update will be later today at 2PM. At this time, university Wi-Fi, UAF Devices Portal, VPN and VDI services have been restored. User Impact: Some services using UA credentials may still fail or show as invalid.

22. monitoring May 19, 2026, 12:18 AM UTC

    As of 3PM on Monday, May 18th, all impacted systems have been restored and continue to be stable. The next update will be 8AM tomorrow. If you continue to experience service login errors, please contact the NTS Service Desk. At this time, university Wi-Fi, UAF Devices Portal, VPN and VDI services have been restored. User Impact: Some services using UA credentials may still fail or show as invalid.

23. monitoring May 19, 2026, 04:21 PM UTC

    As of 8AM on Tuesday, May 19th, all impacted systems have been restored and continue to be stable. The next update will be 8AM tomorrow. If you continue to experience service login errors, please contact the NTS Service Desk. At this time, university Wi-Fi, UAF Devices Portal, VPN and VDI services have been restored. User Impact: Some services using UA credentials may still fail or show as invalid.

24. monitoring May 20, 2026, 04:00 PM UTC

    As of 8AM on Wednesday, May 20th, the primary impacted services have been restored and are currently stable under monitoring. The next update will be tomorrow at 8AM, unless there are any significant changes. At this time, university Wi-Fi, UAF Devices Portal, VPN, and VDI services have been restored.

25. monitoring May 21, 2026, 04:30 PM UTC

    As of 8AM on Thursday, May 21st, the primary impacted services have been restored and are currently stable under monitoring. The next update will be tomorrow at 8AM, unless there are any significant changes. At this time, university Wi-Fi, UAF Devices Portal, VPN, and VDI services have been restored.

26. resolved Jun 01, 2026, 05:05 PM UTC

    Our teams have resolved the issue with the Authentication service, and confirmed the fix to be stable. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

Read the full incident report →

Started May 15, 2026, 10:52 PM UTC· resolved May 18, 2026, 04:25 PM UTC

1. investigating May 15, 2026, 10:52 PM UTC

   We have received reports that ELMO is currently experiencing issues. The UAS ELMO team is currently investigating, and we will be making updates at 30 minute intervals. Thank you for your patience during the resolution of this issue!

2. monitoring May 15, 2026, 11:13 PM UTC

   The UAS ELMO team has identified the issue with ELMO service and has implemented a fix, which is being monitored for effectiveness and stability. Thank you again for your patience during the resolution of this issue! You can expect further updates at the end of the business day (5:00PM) or as new information becomes available.

3. monitoring May 16, 2026, 12:57 AM UTC

   The affected components of ELMO appear to be stable. We will continue monitoring the stability of the fix over the weekend, and you can expect a final update at the start of business (8:00AM) Monday if there is no new information until then. Thank you again for your patience during the resolution of this issue!

4. resolved May 18, 2026, 04:25 PM UTC

   The UAS ELMO team has resolved the issue with the ELMO, and confirmed the fix to be stable. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

Read the full incident report →

Started May 11, 2026, 05:23 PM UTC· resolved May 12, 2026, 04:35 PM UTC

1. monitoring May 11, 2026, 05:23 PM UTC

   We have received reports that UAOnline Employee Login is currently experiencing issues. The OIT Enterprise Applications (EAS) team is aware and has identified the cause. This issue appears to be related to an update to Banner over the weekend that is causing issues for some users. EAS is currently working with the vendor, Ellucian towards a permeant fix. For users experiencing issues, there is a workaround. If getting an error, simply change the "UAA" in the url to either "UAF" or "UAS". Once logged into UAOnline, you should be able to log out and use the Employee Login option without issue. We will make updates on this situation at the end of the business day 5:00pm and as new information becomes available. Thank you for your patience during the resolution of this issue!

2. monitoring May 12, 2026, 12:58 AM UTC

   There are still some users currently experiencing issues with the UAOnline Employee Login. The EAS team is continuing to work with the vendor, Ellucian, towards a permeant fix. For users experiencing issues, there is a workaround. If getting an error stating that the "MEP code is invalid", simply change the "UAA" in the url of the page displaying the error to either "UAF" or "UAS". Once logged into UAOnline, you should be able to log out and use the Employee Login option without issue. If the issue persists, please contact the NTS Service Desk. We will make updates on this situation at the start of the business day 8:00am and as new information becomes available. Thank you for your patience during the resolution of this issue!

3. monitoring May 12, 2026, 04:23 PM UTC

   The OIT EAS team has identified the issue with the UAOnline Employee Login and has implemented a fix, which is being monitored for effectiveness and stability. Thank you again for your patience during the resolution of this issue! You can expect further updates at the end of the business day (5:00PM) or as new information becomes available.

4. resolved May 12, 2026, 04:35 PM UTC

   The OIT EAS team has resolved the issue with the UAOnline Employee Login, and confirmed the fix to be stable. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

Read the full incident report →

Started Apr 28, 2026, 01:06 AM UTC· resolved Apr 29, 2026, 12:57 AM UTC

1. investigating Apr 28, 2026, 01:06 AM UTC

   We have received reports that our ticketing system, TeamDynamix (TDX), is currently experiencing issues processing replies to generated emails. The UAA Enterprise Service Management team is currently investigating, and we will be making updates when we open at 8:00am Alaska Time. Thank you for your patience during the resolution of this issue!

2. monitoring Apr 28, 2026, 03:56 PM UTC

   UAA ESM has applied a workaround and the affected components of TDX appear to be stable. We will continue monitoring the stability of the fix until the end of the business day (5:00PM) today, and you can expect a final update at that time if there is no new information until then. Thank you again for your patience during the resolution of this issue!

3. resolved Apr 29, 2026, 12:57 AM UTC

   The UAA ESM team has resolved the issue with the affected components of TDX, and confirmed the fix to be stable. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

4. postmortem May 27, 2026, 06:26 PM UTC

   This outage was caused by an issue on our vendor’s side. They released the following information: “The issue was caused by a misconfiguration during a maintenance deployment and has now been fully resolved.“

Read the full incident report →

Started Apr 09, 2026, 06:59 PM UTC· resolved Apr 10, 2026, 10:03 PM UTC

1. identified Apr 09, 2026, 06:59 PM UTC

   We have received reports that the Banner Production instance (including UAOnline) is currently experiencing issues. The OIT Enterprise Applications Services team is aware and has contacted the vendor. We will be making updates at 1-hour intervals as they work towards a fix. Thank you for your patience during the resolution of this issue!

2. identified Apr 09, 2026, 08:17 PM UTC

   OIT EAS reports that Ellucian is going to perform a rolling restart of the affected components, so we expect to see services regain functionality one-at-a-time. We'll report on the status of each as new information becomes available, and at our 1-hour intervals! Thank you again for your time and understanding.

3. monitoring Apr 09, 2026, 08:52 PM UTC

   A fix has been implemented and users are reporting access. We will continue to monitor the service and update the status page at 5PM.

4. monitoring Apr 10, 2026, 12:52 AM UTC

   A fix has been implemented and users are reporting access. There have been no new developments, monitoring will continue until tomorrow morning at 8:00AM.

5. investigating Apr 10, 2026, 04:11 PM UTC

   The affected components of Banner and UAOnline appear to be stable. We will continue monitoring the stability of the fix until the 24-hour mark, at approximately 12:52PM today, and you can expect a final update at that time if there is no new information until then. Thank you again for your patience during the resolution of this issue!

6. resolved Apr 10, 2026, 10:03 PM UTC

   The affected components of Banner are still operational, and we are considering the fix to be stable and this outage resolved. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

Read the full incident report →

Started Apr 08, 2026, 07:23 PM UTC· resolved Apr 09, 2026, 08:46 PM UTC

1. investigating Apr 08, 2026, 07:23 PM UTC

   We have received reports that multiple Banner Self-Service services (including UAOnline) are currently unavailable. The OIT Enterprise Applications Services team has reached out to the vendor and is currently investigating, and we will be making updates at 1-hour intervals. Please contact your campus IT helpdesk if you notice other Banner components are affected. Thank you for your patience during the resolution of this issue!

2. investigating Apr 08, 2026, 07:48 PM UTC

   Some users are reporting that functionality has returned, but are still experiencing slowness. We're waiting for further updates from the vendor, Ellucian, and will continue to make updates as new information becomes available and at 1-hour intervals. Thank you for your time.

3. identified Apr 08, 2026, 08:24 PM UTC

   Ellucian reports that they have marked our incident as high-priority, located the cause, and are currently working on a fix. Further updates will continue at 1-hour intervals and as new information becomes available. Thank you for your time!

4. monitoring Apr 08, 2026, 09:33 PM UTC

   A fix has been implemented and users are reporting access. We will continue to monitor the service and update the status page at 5PM.

5. monitoring Apr 09, 2026, 01:04 AM UTC

   A fix has been implemented and users are reporting access. There have been no new developments, monitoring will continue until tomorrow morning at 8:00AM.

6. monitoring Apr 09, 2026, 04:00 PM UTC

   The affected components of UAOnline appear to remain operational! We will continue monitoring the stability of the fix until the 24-hour mark, at approximately 1:30PM today, and you can expect a final update at that time if there is no new information until then. Thank you again for your patience during the resolution of this issue!

7. identified Apr 09, 2026, 07:05 PM UTC

   UAOnline is experiencing slowness and timeouts as a result of a different incident, and details can be found here as we continue to follow that resolution: https://status.alaska.edu/incidents/2141hpy4lvlm

8. resolved Apr 09, 2026, 08:46 PM UTC

   This issue with UAOnline was identified and the fix is stable.

9. postmortem May 06, 2026, 06:33 PM UTC

   UAOnline Partial Outages Problem Impact Analysis Event Occurrence: March \[15, 17, 20 , 23\] 2026 Employee Self Service; April 2, 2026 Employee Self Service; April 7, 2026 Finance Self Service; April 8, 2026 General Self Service # Background UAOnline is the self service portal for Ellucian Banner used as the university’s Enterprise Resource Planning \(ERP\) system. Banner and UAOnline are hosted by the vendor Ellucian, also the maker of the product. From time to time during initial validation of new upgrades, not all defects are experienced. The self service components of Banner include General, Employee, Finance, and Student self service. All of these are separate applications that are made available under the heading UAOnline and navigable between each area after initial login. # Break Down of the Problem Initially Employee Self Service \(ESS\) was impacted with unavailability on March 15, 17, and 20. Upon report of an issue with the instance the vendor was notified and the corrective action was to restart the service. Noted during these times that some end users were able to access the platform while others could not. On March 20th the service owner escalated further related to this issue. Ellucian shared 2 product defects related to ESS that they expected to cause the issue scheduled of the UA production environment in May. Ellucian recommends instituting daily restarts of the Employee Self Service instances to occur in the UA daily maintenance window of 4am to 5am. The earliest Ellucian could schedule was March 25, resulting in another outage on March 23rd and an escalation response to Ellucian to restore service. On April 2nd, after mitigation was in place, ESS failed again and Ellucian further escalated to prepare a fix to address the product defect specifically for ESS. A patched version of ESS was deployed on April 3rd in TEST and validation was reported back to Ellucian on April 6th to go into production. Further issues with ESS were not identified. On April 7th, Finance Self Service\(FSS\) went down and was reported to Ellucian and Ellucian configured daily restarts. April 8th, General Self Service \(GSS\) was reported down and escalations were entered with Ellucian. On April 10, all self service apps were scheduled to be updated similarly to ESS with daily restarts. All but GSS were successful with this update. ‌ # Target State / Goal The Banner and UAOnline services should be available 24 hours a day 7 days a week with the exception of scheduled and planned down time including the daily maintenance window. The system should always be responsive. # Root Cause Analysis Ellucian’s review of the application hosts that were failing showed the available disk filling up related to a large amount of logs being created in a very short period of time. Ellucian attempted to mitigate this with a daily restart, but demonstrated during this time that the issue could manifest in just a few hours. Ellucian traced to specific product defects that they believed were causing the excessive logging issue. They attempted to mitigate this issue by establishing daily restarts and by creating a non-standard custom WAR file for deployment and management of each Self Service Application. Ellucian later discovered that there was a bug in the text manager product component that when using a MEP environment like UA has, could cause the excessive generation of error log messages which is likely what was filling the disk. Ellucian has released an update for each of the Self Service applications out of band to address the product defect. # Develop Countermeasures * Deploy updated version of self service software that addresses the product defect. # Implementation of Countermeasures ‌ * May 10, 2026 - All self service application with the expectation of Employee Self Service \(ESS\) will be updated to the version where the underlying product defect is corrected. ESS has a new defect that will prevent immediate updating. * Future - Apply ESS tier 2 update which corrects the product defect, when the other dependent product defect is resolved. ‌ # Follow Up / Review ‌ May 11, 2026: Verify all self service applications are working as expected. July 5, 2026: Verify status of ESS to be upgraded.

Read the full incident report →

Started Apr 07, 2026, 06:58 PM UTC· resolved Apr 08, 2026, 04:09 PM UTC

1. investigating Apr 07, 2026, 06:58 PM UTC

   We have received reports that Finance Self-Service Banner (the UAOnline 'Finance' tab) is currently experiencing issues. The OIT Enterprise Applications Services team has sent a high-priority ticket to the vendor, and we will be making updates at 3-hour intervals. Thank you for your patience during the resolution of this issue!

2. monitoring Apr 07, 2026, 07:57 PM UTC

   Ellucian has restarted the affected services; Finance SSB and its associated UAOnline tab appear to be functional again! We will monitor the stability of this fix and make another update at the end of the business day (5:00PM) today. Thank you again for your time while we followed the resolution of this issue!

3. monitoring Apr 08, 2026, 12:59 AM UTC

   Ellucian has restarted the affected services; Finance SSB and its associated UAOnline tab appear to be functional again. There have been no new developments, monitoring will continue until tomorrow morning at 8:00AM. Thank you again for your time while we followed the resolution of this issue.

4. resolved Apr 08, 2026, 04:09 PM UTC

   The issue with Finance SSB, and its associated UAOnline tab, was identified. A fix was implemented and the solution is still working after being monitored all night. Marking this as resolved.

Read the full incident report →

Started Apr 02, 2026, 04:24 PM UTC· resolved Apr 03, 2026, 10:15 PM UTC

1. investigating Apr 02, 2026, 04:24 PM UTC

   We have received reports that the Employee login for UAOnline (Employee SSB) is currently experiencing issues including slowness and intermittent login availability. The OIT Enterprise Applications Services team is currently investigating, and we will be making updates at 3-hour intervals. Thank you for your patience during the resolution of this issue!

2. investigating Apr 02, 2026, 06:03 PM UTC

   Further reports indicate Faculty Self-Service (this includes the 'Faculty & Advisor Services' link in UAOnline) may also be impacted. OIT EAS has opened a ticket with the vendor for Banner, and are monitoring their channels of communication for updates. We will continue to make updates as new information becomes available, and at 3-hour intervals. Thanks so much for your time!

3. investigating Apr 02, 2026, 07:30 PM UTC

   The vendor for Banner is currently investigating the cause of this issue. OIT EAS is monitoring their channels of communication for updates. Thank you for your continued patience as we work towards a full resolution. We will continue to make updates as new information becomes available, and at 3-hour intervals.

4. investigating Apr 02, 2026, 07:53 PM UTC

   OIT EAS reports that the vendor has been instructed to restart the affected services, and are awaiting confirmation that the instructed actions have been taken. Once complete, the effectiveness of the solution will be determined. Thank you again for your patience! We will continue to make updates at 3-hour intervals and as new information becomes available.

5. monitoring Apr 02, 2026, 08:39 PM UTC

   The affected services have been reset, and Employee SSB and Faculty SSB through UAOnline both appear to be operational again. We will monitor the stability of this fix, and another update can be expected at the end of the business day (5:00pm) today! Please report any continued issues with Banner and UAOnline to your campus IT helpdesk. Thanks so much again for your time and patience as we followed the resolution of this incident.

6. monitoring Apr 03, 2026, 01:02 AM UTC

   The Employee SSB and Faculty SSB through UAOnline both are operational. We will continue to monitor the stability of this fix, and another update can be expected at the start of the business day (8:00am) tomorrow! Please report any continued issues with Banner and UAOnline to your campus IT helpdesk. Thanks so much again for your time and patience as we followed the resolution of this incident.

7. monitoring Apr 03, 2026, 04:09 PM UTC

   The affected components of UAOnline and Banner appear to remain operational! We will continue monitoring the stability of the fix until the 24-hour mark, at approximately 12:39PM today, and you can expect a final update at that time if there is no new information until then. Thank you again for your patience during the resolution of this issue!

8. resolved Apr 03, 2026, 10:15 PM UTC

   We've received no further reports of UAOnline or Banner service degradation, and are marking this incident as resolved. Please report any issues with these services (and others!) to your campus IT helpdesk as usual. Thank you again, and happy Friday!

Read the full incident report →

Started Apr 01, 2026, 07:15 PM UTC· resolved Apr 01, 2026, 11:46 PM UTC

1. identified Apr 01, 2026, 07:15 PM UTC

   We have received reports that Banner and Banner-related services such as UAOnline are currently experiencing slow load times. The OIT Enterprise Applications Services (EAS) team is aware and is communicating with their vendor. We will be making updates at 3-hour intervals as they work towards a fix. Thank you for your patience during the resolution of this issue!

2. identified Apr 01, 2026, 07:52 PM UTC

   OIT EAS reports that the vendor is actively looking to resolve the issue, and at this time most services seem to be available again, including Banner and Employee Self-Service. Faculty Self-Service still appears to be down. We will continue to make updates at 3-hour intervals and as new information becomes available. Thank you for your time!

3. identified Apr 01, 2026, 10:26 PM UTC

   Ellucian is continuing to work towards a fix for this issue, and no new information has been relayed at this time. Faculty Self-Service appears to be the only service still affected; this includes the 'Faculty & Advisor Services' link in UAOnline. We will make further updates and as new information becomes available, and at the end of the business day (5:00pm) today. Thank you for your time!

4. monitoring Apr 01, 2026, 10:48 PM UTC

   Ellucian reports that the issue has been resolved, and are reviewing to ensure that the fix is permanent. We will monitor the stability of the fix until the beginning of the business day tomorrow (8:00am) and you can expect another update at that time. Please report any continued issues with Banner speed and functionality to your campus IT helpdesk. Thank you again for your time and patience as we followed the resolution of this issue!

5. resolved Apr 01, 2026, 11:46 PM UTC

   OIT EAS reports that Banner and affected services are now fully operational, and expect the fix to be stable. The vendor has identified a root cause for recent Banner performance issues, and a longer-term fix is expected to be applied in May. Please report any continued issues with Banner and UAOnline, if they arise, to your campus IT helpdesk. Thanks so much for your time and patience as we followed the resolution of this incident.

Read the full incident report →

Started Mar 25, 2026, 07:13 PM UTC· resolved Mar 26, 2026, 12:38 AM UTC

1. identified Mar 25, 2026, 07:13 PM UTC

   UAF Facility Services has a planned power outage in Hess Village that is impacting network equipment in Hess Village. That power outage is planned to be complete by 1PM.

2. resolved Mar 26, 2026, 12:38 AM UTC

   UAF Facilities Services has completed work in Hess Village and the impacted network equipment is operating without issue.

3. postmortem Apr 08, 2026, 06:20 PM UTC

   A scheduled power outage in Hess Village affected the wireless network in that area.

Read the full incident report →

Started Mar 23, 2026, 03:47 PM UTC· resolved Mar 23, 2026, 05:51 PM UTC

1. investigating Mar 23, 2026, 03:47 PM UTC

   We have received reports that UAOnline is currently experiencing issues and the Employee Dashboard is intermittently accessible. The OIT Enterprise Application Services team is currently investigating, and we will be making updates at 1-hour intervals. Thank you for your patience during the resolution of this issue!

2. investigating Mar 23, 2026, 03:53 PM UTC

   OIT EAS has re-escalated their existing ticket with the vendor (Ellucian). We will continue to make updates at 1-hour intervals and as new information becomes available. Thank you again for your time!

3. investigating Mar 23, 2026, 05:06 PM UTC

   There has been no new information provided at this time. A ticket with the vendor for UAOnline (Ellucian) is ongoing. We will continue to make updates at 1-hour intervals and as new information becomes available. Thank you again for your time!

4. monitoring Mar 23, 2026, 05:41 PM UTC

   OIT EAS reports that the vendor has restarted the Employee Self-Service application, resolving the intermittent login issues, and the service is now being monitored for stability. Thank you again for your patience during the resolution of this issue! You can expect further updates at the end of the business day (5:00PM) or as new information becomes available.

5. resolved Mar 23, 2026, 05:51 PM UTC

   OIT EAS has confirmed the fix to be stable. Please report any continued issues with this service to your campus's IT helpdesk, and thank you again for your patience during the resolution of this issue!

Read the full incident report →

Started Mar 20, 2026, 05:06 PM UTC· resolved Mar 20, 2026, 06:14 PM UTC

1. identified Mar 20, 2026, 05:06 PM UTC

   We have received reports that the UAOnline Self-Service/Employee Dashboard is currently experiencing issues. The OIT EAS team is aware and has identified the cause to be related to resource issues on the vendor's side; they have started a ticket with the vendor. We will be making updates at 1-hour intervals as they work towards a fix. Thank you for your patience during the resolution of this issue!

2. monitoring Mar 20, 2026, 06:09 PM UTC

   Vendor identified the issue, restarted the affected service, and function was restored. We are currently monitoring for any further issues.

3. monitoring Mar 20, 2026, 06:12 PM UTC

   We are continuing to monitor for any further issues.

4. resolved Mar 20, 2026, 06:14 PM UTC

   Service is restored.

Read the full incident report →

Started Mar 09, 2026, 10:10 PM UTC· resolved Mar 10, 2026, 04:03 PM UTC

1. identified Mar 09, 2026, 10:10 PM UTC

   We have received reports that UA Google is currently experiencing issues. The OIT PAWS team is aware and has identified the cause to be related to a change intended to archive inactive accounts. They are rolling back the change, but we encourage affected users to contact their IT helpdesk to verify that their accounts are properly configured for when the change is rolled out in the future. We will be making updates at 1-hour intervals as we work towards a fix. Thank you for your patience during the resolution of this issue!

2. identified Mar 09, 2026, 11:36 PM UTC

   OIT PAWS has initiated the rollback for the change that resulted in some erroneous disabled accounts. They expect this process to take a few hours. Affected users are still encouraged to contact their campus IT helpdesk to ensure their accounts are configured correctly for the future change! We will continue to make updates at 1-hour intervals and as new information becomes available. Thank you again for your time as we work to resolve this issue!

3. monitoring Mar 10, 2026, 12:43 AM UTC

   The rollback is in-progress and continuing to re-enable affected accounts. OIT PAWS states that once the rollback is complete, the intended change will be implemented again with corrected filters. We will continue to monitor the situation until the corrected change is implemented. Reporting will continue starting at the beginning of the business day (8:00 AM) tomorrow. Thank you again for your time and patience!

4. resolved Mar 10, 2026, 04:03 PM UTC

   The rollback of disabled UA Google accounts has been completed and affected accounts should be accessible again. If your Google account appears to be disabled, please contact your campus IT helpdesk for assistance. Thank you again for your time and patience as we followed the resolution of this issue!

5. postmortem Mar 25, 2026, 06:35 PM UTC

   UA Google User Access Interruption Problem Impact Analysis Event Occurrence: Monday March 9th @ 1:24 PM # Background UA Google Workspace is the primary cloud collaboration service provided by UA OIT to all UA users. At its most basic functions, it provides email inboxes to all users, as well as access to tools such as Docs, Drive, Sheets, and more. # Break Down of the Problem On Monday March 9th at approximately 1:00 PM, OIT PAWs began to conduct a planned activity within UA Workspace that applied archive license status to a predetermined set of accounts that exceeded the recently established account retention policies for cloud services such as Google. ‌ At approximately 1:24 PM, PAWS was notified by UAF NTS via Slack that several users had reached out to the NTS Service Desk, indicating that their access to UA Workspace has been terminated. OIT PAWs began investigating the matter alongside NTS Technicians. At approximately 2:10 PM, the account archival process was halted. NTS SD Technicians were able to assist with immediate account extensions for users who reached out, alongside an un-archival of their user accounts in Workspace. A rollback of the process was initiated, and completed by approximately 3:30 PM. # Target State / Goal All UA users with active status with UA should retain access to their UA Google Workspace accounts. # Root Cause Analysis Investigations with NTS SD Technicians pointed to a common cause: incorrectly extended accounts. The affected accounts all had extended AD statuses, but had mistakenly not been assigned one of the roles used to identify active user accounts. For the most part, this pointed to alumni users that were missing the \`UAF\_Patrons\` role, but also included at least one service account missing a similar role.Of the ~8000/100 000 records processed during this time, we were able to identify approximately 13 user accounts that may have been impacted by this. # Develop Countermeasures NTS SD Technicians began immediate outreach to members of the UA AD team to capture a list of users that may have inappropriately extended accounts \(e.g. missing role types\), in an effort to remediate misidentifying users. ‌ In addition, we would proactively remove any active AD user from archival processing in favor of manual review to avoid similar issues with incorrect account statuses and roles. # Implementation of Countermeasures User filtering criteria were updated immediately. Additionally, this activity was put through UA CAB later the same week for increased visibility. # Follow Up / Review This activity was completed later in the week, on March 12, with no further incident.

Read the full incident report →