Infraly Outage History
Infraly is up right nowPingoru has recorded 13 incidents for Infraly: 13 in the last 12 months and 4 in the last 90 days.
Show as a table
| Month | Incidents | Hours with an open incident |
|---|---|---|
| April 2026 | 0 | 0 of 720 (0%) |
| May 2026 | 4 | 357 of 744 (48%) |
| June 2026 | 0 | 18 of 720 (2%) |
| July 2026 | 0 | 0 of 744 (0%) |
| August 2026 | 0 | 0 of 744 (0%) |
| September 2026 | 4 | 129 of 720 (18%) |
| October 2026 | 0 | 208 of 519 (40%) |
Incidents, newest first
Major September 25, 2026 WISP - Front-end Outage 5m
Started Sep 25, 2026, 03:55 PM UTC· resolved Sep 25, 2026, 04:00 PM UTC
- investigating Sep 25, 2026, 03:55 PM UTC
Since 15:55 UTC, our monitoring has reported WISP front-end services have been periodically inaccessible. Our team is currently looking into the issue. We will provide an update as soon as possible..
- resolved Sep 25, 2026, 04:00 PM UTC
This has been resolved..
Minor September 2, 2026 Infraly - Chicago - Network Connectivity Issues 1h 19m Chicago, Illinois (Equinix CH1), Chicago, Illinois (SBA Edge), Chicago, Illinois (Backbone Network)
Started Sep 02, 2026, 06:52 PM UTC· resolved Sep 02, 2026, 08:11 PM UTC
- investigating Sep 02, 2026, 06:52 PM UTC
We are currently investigating this incident.
- investigating Sep 02, 2026, 07:03 PM UTC
Traffic is traversing the network normally again. We observed a flap on one of our carrier ports that caused a period of packet loss and reachability issues for some customers. We are continuing to monitor the affected port and are working with our transit provider to determine the root cause. We will update this incident once we have more information.
- resolved Sep 02, 2026, 08:11 PM UTC
After further investigation with our transit provider, we traced the instability to a control plane issue on one of our edge routers, which was negatively affecting traffic traversing the associated carrier port. The port itself and our provider's network were not at fault. We have applied adjustments to the affected router to correct the behavior. Traffic has been traversing the network normally since 19:13 UTC, with no recurrence since the changes were made. We will continue to keep additional monitoring on this router. We apologize for the disruption and appreciate your patience. If you are still experiencing issues with your services, please open a ticket with our support team.
Minor May 18, 2026 Infraly - London - Network 49d 4h London, United Kingdom (Telehouse North), London, United Kingdom (Redcentric London City), London, United Kingdom (Backbone Network)
Started May 18, 2026, 05:36 PM UTC· resolved Jul 06, 2026, 09:44 PM UTC
- investigating May 18, 2026, 05:36 PM UTC
We are currently investigating this incident.
- monitoring May 18, 2026, 07:22 PM UTC
Our network provider has implemented a fix on their core network on 2026-05-18 18:37:23 UTC. Since then, our monitoring has shown positive traffic flow traversing the network. We will continue to monitor for the next 24 hours. If no issues, we will mark this as resolved.
- monitoring May 18, 2026, 09:24 PM UTC
Our monitoring is showing this is happening again. We have reached out to our network provider for an update. We will provide an update as soon as possible.
Minor May 17, 2026 Infraly - Chicago - 45.62.160.0/24 Routing Issues 1d 14h Physgun (Game Hosting), Physgun (Dedicated Servers), Physgun (Colocation), Physgun (Premium VPS) and 1 more
Started May 17, 2026, 01:21 AM UTC· resolved May 18, 2026, 03:50 PM UTC
- identified May 17, 2026, 01:21 AM UTC
This prefix is one of our last remaining leased prefixes as we have moved solely to deploying new systems on fully-owned prefixes. From our initial investigation, this routing issue is caused by a bug in our IP leasers systems where their automation removed the ROA and RPKI objects for the IP subnet. These two objects are how internet providers know that a provider, us in this case, is permitted to route traffic to. We are working with the IP leaser to resolve this problem immediately. We will provide updates as soon as possible.
- monitoring May 18, 2026, 07:11 AM UTC
The IP holder has confirmed this was an issue on their end and has re-created the ROA and RPKI objects for 45.62.160.0/24\. As these changes propagate, routing to the prefix will be restored. Most networks should see connectivity return within the next few hours, though some providers may take longer to refresh their RPKI validators.
- resolved May 18, 2026, 03:50 PM UTC
Connectivity to 45.62.160.0/24 has been fully restored across all networks. Due to this incident, we will be phasing out this prefix over the next 1-2 months and migrating affected systems to new prefixes. If your service is affected, you will receive an email with your new IP address(es) and migration details ahead of the change. We apologize for the disruption and appreciate your patience.
Minor January 18, 2026 Infraly - London - LON-P-VPS-1 Memory Replacement – January 18th, 2026 – Overall
Started Jan 18, 2026, 02:30 PM UTC· resolved Jan 18, 2026, 02:30 PM UTC
No vendor updates were posted for this incident.
Minor December 30, 2025 Infraly - London - LON-P-VPS-1 Drive Replacement – December 30th, 2025 – Overall
Started Dec 30, 2025, 01:00 PM UTC· resolved Dec 30, 2025, 01:00 PM UTC
No vendor updates were posted for this incident.
Minor November 24, 2025 Infraly - Global - Gcore-routed Services 38m
Started Nov 24, 2025, 02:02 PM UTC· resolved Nov 24, 2025, 02:40 PM UTC
- investigating Nov 24, 2025, 02:02 PM UTC
At 14:02 UTC, our monitoring reported connectivity issues across Gcore-routed services on our network in Chicago and London. Our team is currently reviewing and will provide updates as needed..
- resolved Nov 24, 2025, 02:40 PM UTC
On November 24th, 2025, at 14:02 UTC, we experienced an issue affecting certain traffic to our Chicago and London locations that was routed through our DDoS mitigation provider, Gcore. Due to the recent and ongoing DDoS activity over the past two months from the unprecedented Aisuru botnet, we had proactively routed a majority of our traffic through Gcore for protection. During this incident, our core network remained healthy, and traffic via other upstream providers continued operating normally. BGP sessions with Gcore also remained up, and they continued to accept and propagate our announcements globally; however, an automation error on Gcore’s side caused their filtering appliances to stop forwarding ingress traffic to our endpoints in Chicago and London. Our monitoring systems alerted us at 14:02 UTC, and our team acknowledged the alert immediately. After investigation, we identified Gcore as the source of the problem and began isolating affected prefixes. At 14:33 UTC, all Chicago Gcore-routed prefixes were shifted to alternative upstream providers, and at 14:40 UTC, we did the same for London Gcore-routed prefixes. Shortly after these changes, traffic levels and service availability for both locations returned to normal. Following our outreach, Gcore confirmed that the disruption was caused by an unintended automation change on their side and acknowledged that this should not have occurred. They quickly corrected the issue, after which we carefully shifted traffic back to Gcore on a per-/24 basis when it was appropriate to do so, based on traffic levels and mitigation needs. We are also reviewing our own routing, automation, and failover procedures to further reduce the impact of any similar provider-side issues in the future. We understand the disruption and inconvenience this incident may have caused and sincerely apologize for the impact on your services. Thank you for your patience while we mitigated the issue and worked with Gcore to restore normal operation. Please note that this incident does qualify for SLA credit. If you were impacted, please open a ticket to receive your credit. Please make sure to include service(s) affected, outage time, total affected outage period, and any other necessary information to assist with administering SLA credit..