Uptime.com Outage History

Uptime.com is up right now

Uptime.com had 42 outages in the last 2 years totaling 1517h 31m of downtime — averaging 1.7 incidents per month.

There were 42 Uptime.com outages since March 28, 2026 totaling 1517h 31m of downtime. Each is summarised below — incident details, duration, and resolution information.

Source: https://status.uptime.com

Minor September 8, 2026

Delayed check state updates in the M2 locations

Detected by Pingoru
Sep 08, 2026, 08:51 AM UTC
Resolved
Sep 08, 2026, 12:15 PM UTC
Duration
3h 23m
Timeline · 3 updates
  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

Read the full incident report →

Minor September 1, 2026

Intermittent slowness when pausing, resuming, or saving checks

Detected by Pingoru
Sep 01, 2026, 05:00 PM UTC
Resolved
Sep 02, 2026, 11:59 PM UTC
Duration
1d 6h
Timeline · 4 updates
  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 →

Minor August 26, 2026

Location Down - Puerto Rico-San Juan

Detected by Pingoru
Aug 26, 2026, 07:25 PM UTC
Resolved
Aug 27, 2026, 12:52 AM UTC
Duration
5h 26m
Timeline · 2 updates
  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 →

Minor August 24, 2026

Location Down - Philippines-Manila

Detected by Pingoru
Aug 24, 2026, 09:40 PM UTC
Resolved
Aug 25, 2026, 04:22 AM UTC
Duration
6h 42m
Timeline · 2 updates
  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 →

Minor August 20, 2026

API check degradation in Germany region

Detected by Pingoru
Aug 20, 2026, 01:59 PM UTC
Resolved
Sep 01, 2026, 11:59 PM UTC
Duration
12d 10h
Timeline · 2 updates
  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 →

Minor August 19, 2026

Intermittent Disruption Affecting Check Execution

Detected by Pingoru
Aug 19, 2026, 08:09 PM UTC
Resolved
Aug 20, 2026, 12:45 AM UTC
Duration
4h 35m
Timeline · 3 updates
  1. investigating 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 →

Minor August 18, 2026

Intermittent SMTP check failures on M2-based servers

Detected by Pingoru
Aug 18, 2026, 02:00 PM UTC
Resolved
Aug 21, 2026, 07:42 AM UTC
Duration
2d 17h
Timeline · 3 updates
  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 →

Major August 17, 2026

Performance Metrics Collection Interrupted

Detected by Pingoru
Aug 17, 2026, 11:18 AM UTC
Resolved
Aug 17, 2026, 02:50 PM UTC
Duration
3h 32m
Timeline · 1 update
  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 →

Major August 17, 2026

Partial probe network outage

Detected by Pingoru
Aug 17, 2026, 05:00 AM UTC
Resolved
Aug 17, 2026, 09:17 AM UTC
Duration
4h 17m
Timeline · 3 updates
  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 →

Minor August 16, 2026

Location Down - US-NV-Las Vegas

Detected by Pingoru
Aug 16, 2026, 11:11 AM UTC
Resolved
Aug 18, 2026, 02:14 PM UTC
Duration
2d 3h
Timeline · 3 updates
  1. investigating Aug 16, 2026, 11:11 AM UTC

    We are currently facing connection issues with the `US-Las Vegas(Fiberhub)-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. identified Aug 17, 2026, 03:05 AM UTC

    The `US-Las Vegas(Fiberhub)-1` probe server is back Online and systems have started to stabilize. IPv4 access is back but IPv6 access is still out. Our service provider experienced 2 large-scale power outages in their Las Vegas data centre resulting in a line card failure in their network routers. We will continue to monitor the probe server to ensure smooth operation and will collaborate with our service provider as necessary for more details.

  3. resolved Aug 18, 2026, 02:14 PM UTC

    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.

Read the full incident report →

Minor August 14, 2026

Location Down - Norway-Oslo

Detected by Pingoru
Aug 14, 2026, 04:37 PM UTC
Resolved
Aug 16, 2026, 02:10 PM UTC
Duration
1d 21h
Timeline · 3 updates
  1. investigating Aug 14, 2026, 04:37 PM UTC

    We are currently facing connection issues with the `NO-Oslo(IPOnly)-2` 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. monitoring Aug 14, 2026, 05:56 PM UTC

    The `NO-Oslo(IPOnly)-2` probe server is back Online and systems have started to stabilize. We will continue to monitor the probe server to ensure smooth operation and will collaborate with our service provider as necessary for more details.

  3. resolved Aug 16, 2026, 02:10 PM UTC

    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.

Read the full incident report →

Major August 12, 2026

Metrics Data Gap — Historical Performance Data

Detected by Pingoru
Aug 12, 2026, 11:30 AM UTC
Resolved
Aug 12, 2026, 01:45 PM UTC
Duration
2h 15m
Timeline · 1 update
  1. resolved Aug 12, 2026, 11:30 AM UTC

    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.

Read the full incident report →

Minor August 11, 2026

Location Down - Taiwan-Taipei

Detected by Pingoru
Aug 11, 2026, 01:00 PM UTC
Resolved
Aug 12, 2026, 02:22 AM UTC
Duration
13h 22m
Timeline · 2 updates
  1. identified Aug 11, 2026, 01:00 PM UTC

    We are currently facing connection issues with the `TW-Taipei(ChiefLY)-1` probe server. Our service provider is reporting an upstream network service disruption affecting their `Taiwan-Taipei` 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 12, 2026, 02:23 AM UTC

    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.

Read the full incident report →

Minor August 10, 2026

Intermittent DNS checks failures in Austria Vienna

Detected by Pingoru
Aug 10, 2026, 01:12 PM UTC
Resolved
Aug 10, 2026, 03:00 PM UTC
Duration
1h 47m
Timeline · 1 update
  1. monitoring Aug 10, 2026, 01:12 PM UTC

    DNS checks on affected nodes were delayed or did not execute, and dependent alerts may not have been delivered. If you rely on DNS monitoring for alerting, treat that window as having incomplete coverage. We have added capacity to affected regions and reduced per-node execution concurrency, which restored normal check execution. A permanent fix for the underlying defect is in progress, and we are adding capacity limits and monitoring to detect this class of failure earlier. Any other alerts originating from other checks are affected by outdated IP white listing rules announced on August 2

Read the full incident report →

Minor August 9, 2026

Intermittent Platform Service Disruption

Detected by Pingoru
Aug 09, 2026, 09:15 AM UTC
Resolved
Aug 31, 2026, 03:56 PM UTC
Duration
22d 6h
Timeline · 5 updates
  1. investigating Aug 09, 2026, 09:15 AM UTC

    We experienced a brief period of intermittent service disruption affecting multiple Uptime.com services. During this time, some users experienced connection timeouts or were unable to access affected services. Service has now recovered, and we are monitoring closely to ensure continued stability. We are reviewing the incident internally and will implement any necessary follow-up actions. We apologize for any inconvenience caused.

  2. monitoring Aug 09, 2026, 10:36 AM UTC

    Affected services have resumed and are currently operating normally. We are continuing to monitor the platform closely while we investigate the cause of the disruption.

  3. monitoring Aug 09, 2026, 12:05 PM UTC

    Services have recovered and are currently operating normally. We identified database lock contention related to bulk scheduled maintenance operations as a contributing factor to the disruption. As a precaution, we have temporarily disabled the bulk scheduled maintenance API endpoint while we continue investigating and implementing additional safeguards. All other platform functionality remains available, and we are continuing to monitor closely for stability.

  4. monitoring Aug 11, 2026, 03:14 PM UTC

    Services have remained stable since our last update, and all monitoring functionality is operating normally. The bulk scheduled maintenance API endpoint remains temporarily disabled while we implement additional safeguards and fixes addressing the database lock contention identified as a contributing factor. All other platform functionality remains fully available. Thank you for your patience. If you experience any further issues, please reach out to our support team.

  5. resolved Aug 31, 2026, 03:56 PM UTC

    This incident is now Resolved. The safeguards and fixes addressing the database lock contention have been implemented, and the bulk scheduled maintenance API endpoint has been re-enabled. All API monitoring and functionality is operating normally. Thank you for your patience. If you continue to experience any issues, please contact our support team.

Read the full incident report →

Minor August 7, 2026

Location Down - Panama-Panama City

Detected by Pingoru
Aug 07, 2026, 02:20 AM UTC
Resolved
Aug 07, 2026, 01:19 PM UTC
Duration
10h 59m
Timeline · 2 updates
  1. investigating Aug 07, 2026, 02:20 AM UTC

    We are currently facing connection issues with the `PA-Panama City(Movistar)-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 07, 2026, 01:19 PM UTC

    We’re pleased to confirm that the connection issues with our `PA-Panama City(Movistar)-1` probe server has 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 →

Minor July 29, 2026

Connectivity Degraded - Netherlands-Amsterdam

Detected by Pingoru
Jul 29, 2026, 04:23 AM UTC
Resolved
Jul 29, 2026, 11:01 AM UTC
Duration
6h 37m
Timeline · 3 updates
  1. investigating Jul 29, 2026, 04:23 AM UTC

    We are currently experiencing connectivity issues affecting a few probe servers in our `Netherlands-Amsterdam` location. This may result in false positives, elevated latency, packet loss, or failed monitoring requests reported specifically from the Netherlands-Amsterdam monitoring location. Probe server/s affected: - ` NL-Amsterdam(IronMountain)-2` Our engineering team is investigating the issue and is working with the relevant provider to restore normal service as quickly as possible. We will share further updates as soon as more information becomes available. Should you require further assistance or have any questions, please do not hesitate to contact our support team.

  2. identified Jul 29, 2026, 05:05 AM UTC

    Our service provider has reported an ongoing infrastructure maintenance in their Amsterdam data centre, which is impacting some servers. Their networking team is actively working to complete the maintenance and restore service to the affected systems as soon as possible. We will continue to monitor the situation closely and provide updates as we receive them. Thank you for your patience and understanding.

  3. resolved Jul 29, 2026, 11:01 AM UTC

    We’re pleased to confirm that network connectivity on the `NL-Amsterdam(IronMountain)-2` probe server has been fully restored and remains stable. The `Netherlands-Amsterdam` 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 →

Minor July 28, 2026

Intermittent DNS resolution timeouts for HTTP checks in APAC region

Detected by Pingoru
Jul 28, 2026, 12:00 PM UTC
Resolved
Jul 30, 2026, 05:18 AM UTC
Duration
1d 17h
Timeline · 5 updates
  1. investigating Jul 28, 2026, 12:00 PM UTC

    HTTP checks are intermittently failing at a few APAC probe locations with DNS lookup timeouts: ``` dial tcp: lookup on x.x.x.x:53: ... i/o timeout ``` Failures are intermittent. The trigger is confirmed, the underlying cause of the dropped/slow lookups is still under investigation. Affected locations: - Japan-Tokyo - Japan-Osaka - Australia-Sydney - Singapore-Singapore (unexpectedly affected; under investigation)

  2. monitoring Jul 29, 2026, 01:14 PM UTC

    The issue has been identified and addressed. We are currently monitoring the situation to ensure that checks recover and systems at the affected locations remain stable. The cause was a DNS resolver misconfiguration that led to occasional domain-name resolution failures, more frequently at geographically distant locations. This has been corrected.

  3. investigating Jul 29, 2026, 05:20 PM UTC

    The issue was only partially mitigated, while we see less domain resolution timeouts, it has not been solved completely. We are rolling out a patch to affected systems

  4. monitoring Jul 29, 2026, 06:09 PM UTC

    A change affected domains resolution configuration has been rolled back. All affected checks should recover shortly. This includes an increased response time from checks executed in affected locations. The system is being actively monitored and the incident will get resolved once we ensure that the issue has been properly addressed

  5. resolved Jul 30, 2026, 05:18 AM UTC

    The issue has been resolved, no new false positives have been seen since yesterdays update

Read the full incident report →

Minor July 24, 2026

Degraded Performance Across Multiple Probe Locations

Detected by Pingoru
Jul 24, 2026, 10:55 AM UTC
Resolved
Jul 24, 2026, 12:05 PM UTC
Duration
1h 10m
Timeline · 1 update
  1. resolved Jul 24, 2026, 10:55 AM UTC

    We have completed our investigation and confirm that the intermittent network connectivity issues affecting a subset of our monitoring probe locations have been resolved. Our Engineering team identified the root cause as instability on Twelve99 transit routes serving the affected locations. Connectivity over these routes has since stabilised, and both IPv4 and IPv6 connectivity are now operating normally across all previously affected probes. All monitoring locations are fully operational, and check execution has returned to normal across the network. No further action is required from customers. We apologize for any inconvenience this may have caused. Should you have any questions or continue to observe anomalies, please contact our support team.

Read the full incident report →

Minor July 16, 2026

Location Down - Bolivia-La Paz

Detected by Pingoru
Jul 16, 2026, 06:00 PM UTC
Resolved
Jul 16, 2026, 10:15 PM UTC
Duration
4h 15m
Timeline · 3 updates
  1. identified Jul 16, 2026, 06:00 PM UTC

    We are currently facing connection issues with the `BO-La Paz(EdgeUno)-1` probe server. Our service provider is reporting an outage in their `La Paz - Bolivia` 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. monitoring Jul 16, 2026, 06:57 PM UTC

    The `BO-La Paz(EdgeUno)-1` probe server is back Online and systems have started to stabilize. We will continue to monitor the probe server to ensure smooth operation and will collaborate with our service provider as necessary for more details.

  3. resolved Jul 16, 2026, 10:15 PM UTC

    We’re pleased to confirm that network connectivity on all affected probe server has been fully restored and remains stable. The `Bolivia-La Paz` location is 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 →

Minor June 30, 2026

Application Performance Degradation

Detected by Pingoru
Jun 30, 2026, 12:54 AM UTC
Resolved
Jun 30, 2026, 05:42 AM UTC
Duration
4h 48m
Timeline · 3 updates
  1. investigating Jun 30, 2026, 12:54 AM UTC

    We are currently experiencing degraded application performance. Some users may encounter intermittent access issues or page errors on uptime.com. Our engineering team is investigating the issue and is actively working on a resolution. We are monitoring the situation closely and will provide updates as new 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 Jun 30, 2026, 04:55 AM UTC

    A fix has been deployed and systems have started to stabilize. We are continuing to closely monitor performance to confirm full stability before marking this incident as resolved. We will provide a further update once monitoring is complete. Thank you for your patience. If you have any questions or require assistance, please feel free to contact our support team.

  3. resolved Jun 30, 2026, 05:43 AM UTC

    Application performance has remained stable following the earlier period of degraded performance and intermittent availability issues. We are marking this incident as resolved. We have reviewed the incident internally and will implement any necessary follow-up actions. We apologize for any inconvenience caused.

Read the full incident report →

Minor June 30, 2026

Decommissioning of Probe Server IP Addresses - 30 June 2026

Detected by Pingoru
Jun 30, 2026, 12:00 AM UTC
Resolved
Jul 07, 2026, 11:59 PM UTC
Duration
7d 23h
Timeline · 1 update
  1. monitoring Jun 30, 2026, 12:00 AM UTC

    As part of our ongoing infrastructure improvements, we are replacing probe servers across several regions. As a result, the following IP addresses will be retired and removed from the Uptime.com IP monitoring range list: - **US-CA-Fremont**: `173.255.240.87`|`2600:3c01::f03c:94ff:fe21:28d9` - **Chile-Santiago**: `64.176.9.55`|`2001:19f0:c800:2a5c:5400:04ff:fe5d:0da9` - **Japan-Osaka**: `64.176.48.147`|`2401:c080:3800:212f:5400:04ff:fe5d:0da1` ### **Action Required:** If you have configured firewall ACLs or allowlists that include any of the IP addresses above, please remove or update those rules starting **30 June 2026** to prevent unintended access policy conflicts. No action is required if you do not explicitly allowlist Uptime.com probe server IPs in your infrastructure. If you have any questions or need assistance, please don't hesitate to contact our support team.

Read the full incident report →

Minor June 26, 2026

Connectivity Degraded - US-NY-New York

Detected by Pingoru
Jun 26, 2026, 10:09 PM UTC
Resolved
Jun 27, 2026, 02:08 PM UTC
Duration
15h 59m
Timeline · 4 updates
  1. investigating Jun 26, 2026, 10:00 PM UTC

    We are currently experiencing connectivity issues affecting all probe servers in our `US-NY-New York` location. This may result in false positives, elevated latency, packet loss, or failed monitoring requests reported specifically from the `US-NY-New York` monitoring location. Probe servers affected: - `US-New York(DigitalRealty)-19` - `US-New York(DigitalRealty)-20` - `US-New York(DigitalRealty)-21` - `US-New York(DigitalRealty)-22` - `US-New York(DigitalRealty)-23` - `US-New York(DigitalRealty)-24` - `US-New York(DigitalRealty)-25` - `US-New York(DigitalRealty)-26` - `US-New York(DigitalRealty)-27` Our engineering team is investigating the issue and is working with the relevant provider to restore normal service as quickly as possible. We will share further updates as soon as more information becomes available. Should you require further assistance or have any questions, please do not hesitate to contact our support team.

  2. identified Jun 26, 2026, 11:15 PM UTC

    Our provider has implemented a fix for the connectivity issues affecting our `US-NY-New York` monitoring location. They are currently monitoring the results to confirm that service has fully stabilised. We will continue to monitor the location and will provide a further update once normal connectivity has been confirmed.

  3. monitoring Jun 27, 2026, 12:22 AM UTC

    We can confirm that the connectivity issue affecting our `US-NY-New York` monitoring location has been resolved. We will continue to monitor the location to ensure service remains stable.

  4. resolved Jun 27, 2026, 02:08 PM UTC

    We’re pleased to confirm that network connectivity on all affected probe server has been fully restored and remains stable. The `US-NY-New York` 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 →