Respondus Outage History

Started Jun 30, 2026, 08:25 PM UTC· resolved Jun 30, 2026, 10:02 PM UTC

1. investigating Jun 30, 2026, 08:25 PM UTC

   We are currently investigating an intermittent issue with some users being unable to start a Respondus Monitor session. Access to the LockDown Browser Dashboard also appears to be affected. Updates to follow.

2. monitoring Jun 30, 2026, 08:59 PM UTC

   The Respondus Monitor service has been restored and should be functioning normally again. We will continue to monitor the service to ensure stability.

3. resolved Jun 30, 2026, 10:02 PM UTC

   Respondus Monitor continues to function normally. No further updates will be provided.

Read the full incident report →

Started Feb 19, 2026, 03:05 PM UTC· resolved Feb 19, 2026, 11:32 PM UTC

1. investigating Feb 19, 2026, 03:05 PM UTC

   We are investigating an issue relating to Canvas New Quizzes that causes LockDown Browser for Mac and iPad to fail at startup. Impact: - LockDown Browser for iPad: Displays a blank screen after the begin button is pressed - LockDown Browser for Mac: Displays error code -379 after the begin button is pressed This issue does NOT affect LockDown Browser for Windows or Chromebook. Those platforms may be used as a temporary workaround while Instructure and Respondus investigate.

2. investigating Feb 19, 2026, 06:13 PM UTC

   We continue to investigate this issue with Instructure.

3. identified Feb 19, 2026, 08:52 PM UTC

   The issue has been identified and Instructure plans to issue a hotfix shortly.

4. resolved Feb 19, 2026, 11:32 PM UTC

   Instructure has deployed a hotfix that resolves the issue causing LockDown Browser for Mac and iPad to fail when launching Canvas New Quizzes.

Read the full incident report →

Started Oct 20, 2025, 03:05 PM UTC· resolved Oct 20, 2025, 09:27 PM UTC

1. investigating Oct 20, 2025, 03:05 PM UTC

   Respondus Monitor is experiencing intermittent issues related to an ongoing AWS incident. The impact is heightened because many users are also unable to launch exams from their learning systems, which are affected by the same AWS disruption. Our development team is actively monitoring the situation as a top priority.

2. investigating Oct 20, 2025, 04:37 PM UTC

   We continue to monitor the widespread AWS outage that has affected many vendors’ ability to scale their systems during periods of high usage. The impact on Respondus Monitor has been limited, as most users were also unable to launch exams from their learning systems due to the same AWS incident. Respondus Monitor remains fully operational, and our development team continues to monitor the situation as a top priority.

3. resolved Oct 20, 2025, 09:27 PM UTC

   Resolved – Respondus Monitor is fully operational and has experienced no service degradation for several hours. Some assessment systems that integrate with Respondus Monitor continue to experience issues related to the AWS outage, which may give the appearance of instability in our service. On our end, all systems are operating normally. We consider this issue resolved but will open a new incident report if new issues arise.

Read the full incident report →

Started Sep 08, 2025, 06:46 PM UTC· resolved Sep 08, 2025, 06:57 PM UTC

1. investigating Sep 08, 2025, 06:46 PM UTC

   Exams using Respondus Monitor are currently experiencing slow response times. We are investigating the issue and will provide updates as we have them.

2. investigating Sep 08, 2025, 06:57 PM UTC

   Performance has now returned to normal. The slowdown has been resolved.

3. resolved Sep 08, 2025, 06:57 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 07, 2025, 10:40 PM UTC· resolved May 07, 2025, 11:15 PM UTC

1. investigating May 07, 2025, 10:40 PM UTC

   We are currently investigating an outage of StudyMate Campus.

2. monitoring May 07, 2025, 10:51 PM UTC

   The service has resumed and we are monitoring the system.

3. resolved May 07, 2025, 11:15 PM UTC

   The service is functioning normally.

Read the full incident report →

Started Mar 05, 2025, 06:10 PM UTC· resolved Mar 05, 2025, 10:17 PM UTC

1. investigating Mar 05, 2025, 06:10 PM UTC

   The Respondus Monitor service is currently experiencing a slowdown. We are investigating the source of the problem.

2. investigating Mar 05, 2025, 06:35 PM UTC

   We continue to experience problems with users being able to start new Respondus Monitor sessions. We will provide another update shortly.

3. investigating Mar 05, 2025, 07:17 PM UTC

   We continue to work with AWS to troubleshoot this issue. Service continues to be degraded for Respondus Monitor. The same issue is impacting Chromebook users of LockDown Browser.

4. investigating Mar 05, 2025, 08:13 PM UTC

   This issue is ongoing and we continue to work with AWS on a resolution. Respondus Monitor users are experiencing very slow response times during the pre-exam steps. Chromebook users are experiencing an outage.

5. investigating Mar 05, 2025, 09:24 PM UTC

   We are seeing improvements across the system. We will continue to monitor it closely and will provide details later about our investigation.

6. investigating Mar 05, 2025, 09:37 PM UTC

   We are continuing to investigate this issue.

7. monitoring Mar 05, 2025, 09:49 PM UTC

   All systems are operational and working properly. We will provide details at a later time about the investigation.

8. resolved Mar 05, 2025, 10:17 PM UTC

   This incident has been resolved.

9. postmortem Mar 07, 2025, 10:36 PM UTC

   Root Cause Analysis for Service Slowdown and Interruption March 5, 2025 We sincerely apologize for the service issues on March 5th that affected some of our applications. We understand how much your institution relies on our services, and we regret any inconvenience this may have caused. Below, we’d like to provide details on what happened and the steps we are taking to prevent future occurrences. At approximately 10:00am PST on March 5, 2025, we started receiving alarms indicating a rapid increase in the failure rate of students starting and completing the pre-exam steps in Respondus Monitor. However, everything appeared normal in the application servers in terms of processing requests, server load, memory usage, and thread and connection counts. Requests were serviced without errors and within our maximum target of 250ms response time. But while all health checks within the AWS environment indicated the servers were healthy and operating normally, we began receiving alerts from monitoring services that run external to AWS showing elevated response times and intermittent failures. We then focused on the AWS load balancer service \(ALB\) which distributes incoming traffic to the application servers. This service is fully managed by AWS, and hence, we don’t have good insight into the health of the appliance, nor can we restart the nodes, etc. After examining the access logs for the load balancer, we saw a very high number of Error 460 entries, which according to the AWS documentation means: "Client errors are generated when requests are malformed or incomplete. These requests were not received by the target, other than in the case where the load balancer returns an HTTP 460 error code. This count does not include any response codes generated by the targets." Our initial thought was that a DDoS attack was flooding the load balancer with malformed packets. But this was quickly ruled out because the requests associated with the errors looked normal in the access logs. Additionally, our Global Accelerator endpoints are protected by AWS Shield, which should stop network layer attacks before they reach the load balancer. However, this explained why the application servers appeared to be operating normally – because a large percentage of requests were not reaching them. Engineers at AWS said the 460 errors would also occur if the client \(LockDown Browser\) closes the connection before the load balancer sends the response. This seemed implausible because there hadn’t been recent updates to the client applications. Moreover, such an issue would emerge gradually – over days or weeks – based on how we introduce new releases. This event escalated in minutes. Concurrently with our investigation, we performed two rolling restarts of the application servers which didn't result in much improvement. Given these symptoms, we suspected the issue might be with the load balancer service itself. We decided to terminate all application servers at once \(to fully scale down the load balancer\) and then launch new application servers \(to scale up the load balancer, but on different nodes\). This had the immediate effect of restoring the service, and our initial theory was that the load balancer had gotten into a bad state. After further investigation, however, we determined the problem wasn’t with the load balancer. The root cause was that a bandwidth limit had been reached on the elastic network interfaces attached to the application server instances, resulting in a bottleneck that continued to grow in the early stages as failed requests were retried. This service event primarily entailed slowdowns in request responses and intermittent failures. Once students entered an exam, this event would not have affected them until after the exam was submitted on the learning system. At that point, students may have experienced delays or failures as they attempted to exit the Respondus Monitor system. The only time there was a complete outage was when everything was shut down for a few minutes to restart the entire service. We have since performed a detailed analysis of the event and have configured new alarms that trigger auto-scaling of application servers before the network bandwidth limit is reached. We have also increased the minimum number of application servers which will smooth the opening minutes of a massive autoscaling event. Finally, we also want to note that the StudyMate Campus service was similarly affected during this event, as were users trying to start exams using the Chromebook version of LockDown Browser. In the latter case, the impact was due to how the Chromebook extension retrieves settings at startup.

Read the full incident report →

Started Feb 13, 2025, 07:36 PM UTC· resolved Feb 13, 2025, 07:47 PM UTC

1. investigating Feb 13, 2025, 07:36 PM UTC

   We are investigating an issue where some Respondus Monitor users are unable to complete the steps that occur prior to the start of an exam.

2. investigating Feb 13, 2025, 07:36 PM UTC

   We are continuing to investigate this issue.

3. resolved Feb 13, 2025, 07:47 PM UTC

   The service is now operating normally. The earlier slowdown is being investigated.

Read the full incident report →