Uptime.com Outage History

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.

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.

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.

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

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 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.

From Sep 29, 2:00 PM to Sep 30, 1:30 PM, 5 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.

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.

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.

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

The system has stabilized.

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.

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.

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

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.

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

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.

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

We’re pleased to confirm that IPv4 and IPv6 network connectivity on the `US-Las Vegas(Fiberhub)-1` probe server has been fully restored and remains stable. The `US-NV-Las Vegas` 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.

We’re pleased to confirm that the connection issues with our `NO-Oslo(IPOnly)-2` 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.

During a routine deployment, an internal message queue reached its storage capacity, which temporarily prevented performance metrics from being recorded. Approximately 2.5 hours of historical performance data (response times and related data points visible in check performance graphs) were not captured and cannot be backfilled. Check execution, uptime monitoring, and alerting were not affected at any point during this incident — all checks continued to run and alerts were delivered normally. The metrics recording pipeline has been fully restored. All systems are operating normally and performance metrics are being recorded as expected. We are implementing additional safeguards to prevent this class of issue from recurring.

We’re pleased to confirm that the connection issues with our `TW-Taipei(ChiefLY)-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.