Uptime.com Outage History

Started Nov 01, 2026, 02:30 PM UTC· resolved Nov 01, 2026, 07:08 PM UTC

1. investigating Nov 01, 2026, 02:30 PM UTC

   We are currently experiencing an outage at the `US-NV-Las Vegas` location, specifically affecting the `US-Las Vegas(Fiberhub)-1` probe server. Our Engineering team is actively working with the provider to resolve this issue as quickly as possible. We will provide updates as soon as they become available. Should you require further assistance or have any inquiries, please do not hesitate to contact our support team.

2. resolved Nov 01, 2026, 07:09 PM UTC

   We are pleased to inform you that the `US-NV-Las Vegas` location is now stable and fully operational. Services have been restored, and all probe servers are functioning as expected. Thank you for your patience and understanding during this time.

Read the full incident report →

Started Oct 29, 2026, 10:28 AM UTC· resolved Oct 29, 2026, 11:56 AM UTC

1. identified Oct 29, 2026, 10:28 AM UTC

   Since October 29, 10:28 UTC, some checks from our `Singapore-Singapore`, `India-Bangalore`, `Australia-Melbourne` and `South Korea-Seoul` monitoring locations may not be running as expected. Customers may see missed or failed checks from these locations during this time. The cause is a network connectivity problem between these locations and our central monitoring systems. It is not caused by customer systems. Our engineering team has identified the problem and is working to restore normal service. We will share further updates as they become available. If you have any questions or need assistance, please contact our support team.

2. resolved Oct 29, 2026, 11:58 AM UTC

   We're pleased to confirm that checks from our `Singapore-Singapore`, `India-Bangalore`, `Australia-Melbourne` and `Korea-Seoul` monitoring locations are running as expected again. Between 10:28 and 11:29 UTC on October 29, 2026, some checks from these locations may not have run as expected, and customers may have seen missed or failed checks during this period. The issue was caused by a network connectivity problem between these locations and our central monitoring systems. This issue was not caused by customer systems or configurations. Network connectivity has been restored, and our engineering team has confirmed that all checks from these locations are running normally. No action is required from customers. We apologize for any inconvenience caused. Thank you for your patience. If you experience any further issues, please feel free to reach out to our support team.

Read the full incident report →

Started Oct 27, 2026, 11:35 AM UTC· resolved Oct 27, 2026, 03:23 PM UTC

1. identified Oct 27, 2026, 11:35 AM UTC

   Between 11:35 and 13:10 UTC today, a change to how monitoring alerts are delivered caused some checks to remain marked as down after a brief failure, even once the monitored service had recovered. Affected checks may have sent down notifications and may still be showing as down. We rolled back the change at 13:10 UTC, so new results are being handled normally again. We are now clearing the checks that are still incorrectly showing as down. No action is needed on your side.

2. resolved Oct 27, 2026, 03:24 PM UTC

   All checks affected by this issue have been reset and now reflect their current status. The change was rolled back at 13:10 UTC and alerting has been working normally since. Monitoring itself was not affected: our locations continued to run and record checks normally throughout. We apologise for the incorrect alerts and are reviewing our release process to prevent this from happening again.

Read the full incident report →

Started Oct 26, 2026, 03:27 PM UTC· resolved Oct 26, 2026, 07:04 PM UTC

1. identified Oct 26, 2026, 03:27 PM UTC

   Since October 26, 15:27 UTC, some checks from our `Australia-Sydney`, `Bulgaria-Sofia`, `Germany-Munich` and `Singapore-Singapore` monitoring locations may not be running as expected. Customers may see missed or failed checks from these locations during this time. The cause is a problem with the network equipment that connects our servers at these locations. It is not caused by customer systems. Our engineering team has identified the problem and is working to restore normal service, and some locations are already starting to recover. We will share further updates as they become available. If you have any questions or need assistance, please contact our support team.

2. identified Oct 26, 2026, 04:27 PM UTC

   Checks from our `Bulgaria-Sofia` and `Germany-Munich` monitoring locations have recovered and are running as expected. Some checks from our Australia-Sydney and Singapore-Singapore locations may still not be running as expected. Our engineering team is continuing to work on restoring normal service at these locations. We will share further updates as they become available. If you have any questions or need assistance, please contact our support team.

3. resolved Oct 26, 2026, 07:05 PM UTC

   We're pleased to confirm that checks from our `Australia-Sydney`, `Bulgaria-Sofia`, `Germany-Munich` and `Singapore-Singapore` monitoring locations are running as expected again. Between 15:27 and 18:36 UTC on October 26, 2026, some checks from these locations may not have run as expected, and customers may have seen missed or failed checks during this period. The issue was caused by a problem with the network equipment that connects our servers at these locations. This issue was not caused by customer systems or configurations. Our engineering team has restored service and confirmed that all checks from these locations are running normally. No action is required from customers. We apologize for any inconvenience caused. Thank you for your patience. If you experience any further issues, please feel free to reach out to our support team.

Read the full incident report →

Started Oct 16, 2026, 01:47 AM UTC· resolved Oct 16, 2026, 04:09 AM UTC

1. investigating Oct 16, 2026, 01:47 AM UTC

   We are currently facing connection issues with the `Default Test Server #2 - GB-London` probe server. Our Engineering team is working closely with the provider to resolve the issue swiftly. We will provide updates as soon as they become available. For the meantime, you may continue to use the `Default Test Server #1 - US-Central` test server. Should you require further assistance or have any inquiries, please do not hesitate to contact our support team.

2. identified Oct 16, 2026, 03:10 AM UTC

   We have identified the cause of the connection issues with the `Default Test Server #2 - GB-London` probe server. Our service provider is performing emergency maintenance on the physical host supporting this probe server to apply a critical security patch. The probe server will be unavailable during the maintenance, which the provider expects to take 30 to 60 minutes. It will come back online automatically once the maintenance is complete. Our Engineering team is monitoring the situation closely with the provider and will confirm the probe server is fully operational once it is back online. We will provide updates as soon as they become available. In the meantime, you may continue to use the `Default Test Server #1 - US-Central` test server. Should you require further assistance or have any inquiries, please do not hesitate to contact our support team.

3. identified Oct 16, 2026, 03:48 AM UTC

   The `Default Test Server #2 - GB-London` probe server remains unavailable. The emergency maintenance by our service provider on the physical host supporting this probe server is taking longer than initially expected. Our Engineering team has followed up with the provider and is working with them to bring the probe server back online as soon as possible. We will provide updates as soon as they become available. In the meantime, you may continue to use the `Default Test Server #1 - US-Central` test server. Should you require further assistance or have any inquiries, please do not hesitate to contact our support team.

4. monitoring Oct 16, 2026, 04:00 AM UTC

   The `Default Test Server #2 - GB-London` probe server is back online following the completion of our service provider's emergency maintenance, and systems have started to stabilize. Our Engineering team will continue to monitor the probe server closely to ensure smooth operation. We will provide a final update once we have confirmed the issue is fully resolved. In the meantime, should you experience any issues with this test server, you may continue to use the `Default Test Server #1 - US-Central` test server. Should you require further assistance or have any inquiries, please do not hesitate to contact our support team.

5. resolved Oct 16, 2026, 04:10 AM UTC

   We're pleased to confirm that the connection issues with our `Default Test Server #2 - GB-London` probe server have been resolved. Our service provider has completed the emergency maintenance, and the probe server is back online and functioning as expected. Thank you for your patience while we worked with our provider to restore connectivity. If you experience any further issues, please reach out to our support team.

Read the full incident report →

Started Oct 14, 2026, 12:40 AM UTC· resolved Oct 14, 2026, 12:15 PM UTC

1. resolved Oct 14, 2026, 12:40 AM UTC

   Between approximately 00:40 and 12:15 UTC on October 14, 2026, monitoring services were disrupted across several probe locations due to an infrastructure availability issue involving a third-party hosting provider. During this period, **monitoring checks assigned to the affected locations were unable to execute**, resulting in gaps in monitoring coverage from those locations. **Affected locations:** - Philippines-Manila - Argentina-Buenos Aires - Indonesia-Jakarta - Saudi Arabia-Riyadh - Colombia-Bogota-M2 The underlying issue has been resolved, and monitoring services have resumed across all affected locations. We are reviewing additional safeguards to improve the detection and escalation of similar infrastructure disruptions. We apologise for any inconvenience caused.

Read the full incident report →

Started Oct 13, 2026, 04:00 PM UTC· resolved Oct 13, 2026, 08:34 PM UTC

1. investigating Oct 13, 2026, 04:00 PM UTC

   We are experiencing connection issues with our probe servers in the `Germany-Berlin` location. This is currently resulting in data packet loss and high latency rates of both inbound and outbound IPv4+IPv6 traffic across multiple locations. Server/s affected: - `DE-Berlin(IONOS)-1` Our engineering team is actively collaborating with the provider to resolve the problem as quickly as possible. We will share updates as soon as we have new information. Should you require further assistance or have any inquiries, please do not hesitate to contact our support team.

2. monitoring Oct 13, 2026, 07:14 PM UTC

   Network connectivity to the `DE-Berlin(IONOS)-1` probe server has been restored, and IPv4+IPv6 packet loss in our `Germany-Berlin` location has cleared. We will continue to monitor the location to ensure service remains stable, and will provide a further update once normal connectivity has been confirmed. Should you require further assistance or have any inquiries, please do not hesitate to contact our support team.

3. resolved Oct 13, 2026, 08:35 PM UTC

   IPv4+IPv6 connectivity to the `DE-Berlin(IONOS)-1` probe server is UP and all systems are stable. The `Germany-Berlin` location is now fully operational and network connectivity is normal. Thank you for your patience. If you experience any further issues, please reach out to our support team.

Read the full incident report →

Started Oct 10, 2026, 12:00 AM UTC· resolved Oct 10, 2026, 02:32 AM UTC

1. resolved Oct 10, 2026, 12:00 AM UTC

   Between 00:00 UTC and 02:32 UTC on October 10, 2026, DOWN and recovery (UP) alerts for checks running from some of our monitoring locations were delayed. Checks continued to run throughout, but changes in check status were not processed on time, and the status shown for some checks may have been out of date during this period. After the fix, the delayed status changes were processed and their alerts were sent, the last of them by 03:25 UTC. Alert times may be later than when the status actually changed. The issue was caused by a failed scheduled maintenance task on one of our internal databases. This issue was not caused by customer systems or configurations. Our engineering team applied a fix at 02:31 UTC, and alerting has operated normally since 02:32 UTC. Affected checks have updated to their correct status. You do not need to do anything. We are reviewing how this maintenance task is monitored to prevent a recurrence. We apologize for the disruption this caused. If you have any questions or require assistance, please feel free to contact our support team.

Read the full incident report →

Started Oct 01, 2026, 04:56 AM UTC· resolved Oct 08, 2026, 02:40 PM UTC

1. resolved Oct 01, 2026, 04:56 AM UTC

   Between October 1 and October 8, 2026, monitoring checks running from our Singapore-Singapore location may have experienced intermittent timeouts, packet loss, and false-positive alerts. Our investigation identified a connection tracking capacity limitation on the Singapore network gateway, which caused some new connections to be dropped. The network configuration was corrected at approximately 14:40 UTC on October 8, resulting in a significant reduction in monitoring failures. We apologize for the disruption and any false-positive alerts generated during this period.

Read the full incident report →

Started Oct 01, 2026, 01:00 AM UTC· resolved Oct 01, 2026, 03:21 PM UTC

1. investigating Oct 01, 2026, 01:00 AM UTC

   #### Summary Some checks from the Singapore and Australia-Sydney locations used IP addresses that are not on our published list. If your firewall only allows our published IP addresses, these checks can fail and cause false DOWN alerts. We are still confirming the IP addresses used in Sydney. #### Affected IP Addresses | Country - City | Family | Old IP (published) | New IP (observed) | |---|---|---|---| | Singapore - Singapore | IPv4 | 139.162.35.94 | 172.104.47.196 | | Singapore - Singapore | IPv6 | 2400:8901:e001:56b::1 | 2400:8901::2000:efff:fec3:d889 | | Australia - Sydney | IPv4 | 172.105.167.54 | | | Australia - Sydney | IPv6 | 2400:8907:e001:303::1 | | #### Impact Only some checks from Singapore-Singapore and Sydney-Australia are affected. Other locations work normally. The published IP addresses have not changed. #### Next Update We will send an update when the issue is resolved.

2. monitoring Oct 01, 2026, 08:41 AM UTC

   Servers were re-attached to the original IPs. We are monitoring the situation

3. resolved Oct 01, 2026, 03:22 PM UTC

   The Australia-Syndey and Singapore servers were stable for the last several hours. Resolving the incident

Read the full incident report →

Started Sep 30, 2026, 08:57 PM UTC· resolved Oct 01, 2026, 01:00 AM UTC

1. resolved Sep 30, 2026, 08:57 PM UTC

   From September 30, 20:57 UTC to October 1, 01:00 UTC, checks from our `Sydney, Australia` locations were interrupted. During this period, affected customers may have seen failed or missed check results, and related alerts, from the said location. The interruption was caused by a network outage at our infrastructure provider, which disrupted traffic to our Sydney servers. Our servers did not recover automatically after the network disruption, which extended the impact. This issue was not caused by customer systems or configurations. Our engineering team restored service at 01:00 UTC, and all checks from these locations are now running normally. No action is required from customers. We are making changes so that our servers recover automatically from this type of network event in the future. We apologize for the disruption and thank you for your patience.

Read the full incident report →

Started Sep 30, 2026, 01:38 PM UTC· resolved Sep 30, 2026, 01:45 PM UTC

1. resolved Sep 30, 2026, 01:38 PM UTC

   From Sep 29, 2:00 PM to Sep 30, 1:30 PM, 6 probe locations did not use the IPv4 addresses that are on our published probe list. During this time, these locations sent checks from their native provisioned IPv4 addresses. Checks continued to run from the correct locations and the results were correct. But if your firewall or allowlist permits only the IPv4 addresses on our probe list, checks from these locations were possibly blocked. This can cause false alerts. We found and fixed the cause. All traffic from these locations now goes through the IPv4 addresses on our published probe list again. You do not need to do anything.

Read the full incident report →

Started Sep 30, 2026, 10:03 AM UTC· resolved Sep 30, 2026, 10:07 AM UTC

1. resolved Sep 30, 2026, 10:03 AM UTC

   From September 29, 21:00 UTC to September 30, 08:00 UTC, checks from some of our monitoring locations did not run. Some customers saw more failed or missed checks from these locations during this period. A network problem at our infrastructure provider interrupted traffic on our servers at these locations, and our servers did not recover automatically. It was not caused by customer systems. We repaired the problem, and all checks from these locations now run correctly. We are making changes so that our servers recover automatically after this type of event in the future. We apologize for the problem that this caused.

Read the full incident report →

Started Sep 29, 2026, 02:30 PM UTC· resolved Sep 29, 2026, 09:00 PM UTC

1. investigating Sep 29, 2026, 02:30 PM UTC

   ### Summary On September 29, we moved the NYC and LAX probe locations to our new monitoring platform. During this migration, some checks ran later than their schedule. ### Impact - **HTTP checks:** execution was delayed from 2:15 PM to 3:15 PM UTC (approximately 1 hour). - **Transaction checks:** execution was delayed from 2:15 PM to 9:00 PM UTC (approximately 7 hours). - Only the NYC and LAX locations were affected. All other locations operated normally. - During the delay, alerts and results from these locations could arrive late. ### Cause The new platform had a higher load in these two locations than we expected. Some components did not have sufficient capacity for this load. This caused a queue of checks that were waiting to run. ### Resolution Our engineering team did these steps: - Corrected a flow-control issue in the HTTP check service. - Added more capacity for Transaction checks in both locations. - Increased the capacity of internal supporting services. - Did an inspection of all servers in NYC and LAX. At 3:15 PM UTC, HTTP checks ran on schedule again. At 9:00 PM UTC, Transaction checks ran on schedule again. ### Next steps This was the last large migration to the new platform. Our team now focuses on the stability of the platform. We will also add more monitoring to find delays in check execution earlier. We apologize for this problem. If you have questions, please contact our support team.

Read the full incident report →

Started Sep 29, 2026, 10:22 AM UTC· resolved Sep 29, 2026, 10:33 AM UTC

1. resolved Sep 29, 2026, 10:22 AM UTC

   Between 10:22 and 10:33 UTC on September 29, 2026, monitoring checks running from our Australia-Sydney and Singapore-Singapore locations may have experienced DNS resolution failures and timeouts. The issue was caused by a network configuration rollout that briefly interrupted connectivity between our probe servers and their internal DNS resolvers. Connectivity was restored, and monitoring checks resumed normal operation. We apologize for any inconvenience caused.

Read the full incident report →

Started Sep 22, 2026, 06:00 PM UTC· resolved Oct 01, 2026, 03:22 PM UTC

1. investigating Sep 22, 2026, 06:00 PM UTC

   #### Summary Since **September 22 at 18:00 UTC**, changes to secrets in Vault have not been reaching the monitoring nodes. This started after checks moved to the new check manager. Checks that use Vault secrets keep running with the last value each node had before the move. If a secret has been rotated or changed since then, checks using it may fail or report wrong results. The issue is still ongoing. #### Impact - **Affected:** checks that use Vault secrets (credentials, tokens, headers, variables) and whose secret was updated after the migration - **Not affected:** checks that don't use Vault secrets, and checks whose secrets haven't changed since the migration - **What users see:** [false DOWN alerts or authentication failures on checks using rotated credentials / no visible effect for most accounts] - **Duration:** ongoing, about 9 days so far (since September 22 at 18:00 UTC)

2. resolved Oct 01, 2026, 03:22 PM UTC

   The secret cache propagation has been fixed, the vault is back and a fully operational

Read the full incident report →

Started Sep 08, 2026, 08:51 AM UTC· resolved Sep 08, 2026, 12:15 PM UTC

1. identified Sep 08, 2026, 08:51 AM UTC

   Impact: Some checks did not update their state. A check could stay in its last known state (for example UP or DOWN) longer than expected. During this period, state changes were delayed and some alert notifications were delayed. Checks continued to run, and check results were collected. No monitoring data was lost. We are investigating an issue with check state processing in one monitoring region. Some checks show a stale state and do not transition between UP and DOWN as expected. Alert notifications for affected checks can be delayed.

2. monitoring Sep 08, 2026, 11:21 AM UTC

   A patch has been released to tolerate intermediate failures on a large amount of state transitions. The system is back to normal, we are monitoring the state.

3. resolved Sep 10, 2026, 01:51 PM UTC

   This incident is now resolved. The corrective patch released to tolerate intermediate failures on a large amount of state transitions has been deployed and validated under normal production load. Thank you for your patience. If you continue to experience any issues, please contact our support team.

Read the full incident report →

Started Sep 01, 2026, 05:00 PM UTC· resolved Sep 02, 2026, 11:59 PM UTC

1. investigating Sep 01, 2026, 05:00 PM UTC

   We're investigating slowness when pausing, resuming, or saving checks. Some of these actions may take several seconds to complete. Monitoring itself is unaffected - checks are still running and alerting normally.

2. identified Sep 02, 2026, 02:30 PM UTC

   We've identified the cause as elevated load on the internal system that synchronizes check state. This is causing delays of up to 5 seconds when pausing, resuming, or saving a check. The requested changes are still being applied correctly, just with a delay. No monitoring, alerting, or data collection has been impacted.

3. monitoring Sep 02, 2026, 02:32 PM UTC

   This incident should be resolved. We are monitoring our system. Between 5PM and 9 PM UTC, pausing, resuming, and saving checks intermittently took up to 5 seconds to complete due to elevated load on our internal service. All changes submitted during this period were applied successfully, and monitoring and alerting were unaffected throughout. We've since reduced load on the affected system and are making changes to prevent a recurrence.

4. resolved Sep 03, 2026, 09:38 AM UTC

   The system has stabilized.

Read the full incident report →

Started Aug 26, 2026, 07:25 PM UTC· resolved Aug 27, 2026, 12:52 AM UTC

1. identified Aug 26, 2026, 07:25 PM UTC

   We are currently facing connection issues with the `PR-San Juan(EdgeUno)-1` probe server. One of our service provider is experiencing an outage in their Puerto Rico-San Juan data centre. Our Engineering team is working closely with the provider to resolve the issue swiftly. We will provide updates as soon as they become available. Should you require further assistance or have any inquiries, please do not hesitate to contact our support team.

2. resolved Aug 27, 2026, 12:52 AM UTC

   We’re pleased to confirm that the connection issues with our `PR-San Juan(EdgeUno)-1` probe server have been resolved. All systems are back online and functioning as expected. Thank you for your patience while we worked with our provider to restore connectivity.

Read the full incident report →

Started Aug 24, 2026, 09:40 PM UTC· resolved Aug 25, 2026, 04:22 AM UTC

1. investigating Aug 24, 2026, 09:40 PM UTC

   We are currently facing connection issues with the `PH-Manila(PLDT)-1` probe server. Our Engineering team is working closely with the provider to resolve the issue swiftly. We will provide updates as soon as they become available. Should you require further assistance or have any inquiries, please do not hesitate to contact our support team.

2. resolved Aug 25, 2026, 04:22 AM UTC

   We’re pleased to confirm that the connection issues with our `PH-Manila(PLDT)-1` probe server have been resolved. All systems are back online and functioning as expected. Thank you for your patience while we worked with our provider to restore connectivity.

Read the full incident report →

Started Aug 20, 2026, 01:59 PM UTC· resolved Sep 01, 2026, 11:59 PM UTC

1. identified Aug 20, 2026, 01:59 PM UTC

   We noticed a degraded performance of API checks in Frankfurt which may result in intermitted failures or delayed check execution. Munich might suffer from the same consequences. We are working on addressing performance issues related to API checks in API-checks heavy regions

2. resolved Sep 03, 2026, 09:37 AM UTC

   An API check has been optimized to work more efficiently with complex logic

Read the full incident report →

Started Aug 19, 2026, 08:09 PM UTC· resolved Aug 20, 2026, 12:45 AM UTC

1. identified Aug 19, 2026, 08:09 PM UTC

   We are experiencing intermittent service disruption affecting Uptime.com checks. A subset of checks may execute inconsistently or return inaccurate results during this period. We have identified the cause as a recent production release. Our engineering team is actively mitigating the impact and is preparing a corrective patch for deployment. Monitoring data and alerting for affected checks may be incomplete for the duration of this incident. No other platform services are currently impacted. We are treating this issue with high priority and will continue to provide updates as our investigation progresses and additional information becomes available. If you have any questions or require assistance, please feel free to contact our support team. We apologize for any disruption this may cause.

2. monitoring Aug 19, 2026, 11:05 PM UTC

   Our engineering team has deployed a corrective patch addressing the issue introduced by the recent production release. Check execution has returned to expected behavior, and we are no longer observing inconsistent results across affected checks. We are continuing to monitor platform stability closely to confirm the fix holds under normal production load. Checks that failed to execute during the disruption window may show gaps in historical data. We will confirm full resolution once we have validated sustained normal operations. Thank you for your continued patience.

3. resolved Aug 20, 2026, 02:46 AM UTC

   This incident is now resolved. Check execution has returned to expected behavior, and we are no longer observing inconsistent results across affected checks. The corrective patch addressing the issue introduced by the recent production release has been deployed and validated under normal production load. Thank you for your patience. If you continue to experience any issues, please contact our support team.

Read the full incident report →

Started Aug 18, 2026, 02:00 PM UTC· resolved Aug 21, 2026, 07:42 AM UTC

1. identified Aug 18, 2026, 02:00 PM UTC

   We are experiencing intermittent failures of SMTP checks running on new node types. We will provide an update in an hour once we identify the cause.

2. investigating Aug 18, 2026, 05:09 PM UTC

   We found an incorrect network setup in our servers from one of our providers, we are working to resolve it as soon as possible. The list of affected locations has been reduced

3. resolved Aug 21, 2026, 07:42 AM UTC

   A network configuration has been updated. SMTP checks are back to normal

Read the full incident report →

Started Aug 17, 2026, 11:18 AM UTC· resolved Aug 17, 2026, 02:50 PM UTC

1. resolved Aug 17, 2026, 11:18 AM UTC

   Between 11:18 and 14:50 GMT on August 17, an issue in our platform interrupted the collection of historical performance metrics. Check execution and alerting were not affected. All checks continued to run on schedule and alerts were delivered normally throughout this period. Performance metrics recorded during the affected window were not stored and cannot be recovered. Customers will see a gap in metrics charts and reports covering this time range. The issue is fully resolved and metrics collection is operating normally. We have made changes to prevent this from recurring. Uptime and downtime records, including SLA calculations, are unaffected.

Read the full incident report →

Started Aug 17, 2026, 05:00 AM UTC· resolved Aug 17, 2026, 09:17 AM UTC

1. identified Aug 17, 2026, 07:00 AM UTC

   We are investigating a disruption that affects a subset of our global checking infrastructure. Checks that run from these locations produce no results and send no alerts for the duration of this incident. For the duration of this incident, checks from these locations produced no results and sent no alerts. Treat this period as a missing data interval in your check history. Checks from all other locations, and all other platform functions, operate normally. We will give an update in an hour

2. monitoring Aug 17, 2026, 08:29 AM UTC

   We identified the cause. A fault in our scheduling layer dispatched check runs too late, so the runs expired before the affected probe locations could start them. This is why the locations produced no results and sent no alerts. We are applying a correction to the scheduling layer and we are clearing the affected runs. Checks from all other locations continue to operate normally. We will give an update in 30 minutes.

3. resolved Aug 17, 2026, 09:17 AM UTC

   We have doubled capacity of our scheduling layer to keep up with an increasing load of active check runs. The system is back to normal

Read the full incident report →