There were 5 LUMASERV outages since February 11, 2026 totaling 3h 20m of downtime. Each is summarised below — incident details, duration, and resolution information.
During routine maintenance work, we encountered a service degration at our Zurich datacenter, which affects one hypervisor and the VM's running on it. We are currently investigating this issue and keep you updated here.
The issue has been identified and resolved.
At March 10, 2026, 11:13 AM, our monitoring alerted that the customer MySQL database was not available. The issue affects managed web hosting services which are operated within our Kubernetes clusters.
We are still investigating an issue with the VM's running the database.
The incident has been resolved and the environments are all available again. We will provide further information with our postmortem.
We encountered packet loss on virtual machines during a network reload in our virtualization environment when provisioning new SDN settings. The issue was resolved by March 8, 2026, 0:30. Moving forward, we will implement measures to ensure that network reloads do not cause packet loss. We will therefore announce the according maintenance frame here on the statuspage.
We are currently experiencing a network outage at our location in Frankfurt. We are currently investigating and provide updates on this page as soon as possible.
The network is available again since 19:24 CET. We continue investigating and analyzing the route cause.
The incident has been resolved and no further impact is expected. We will provide details today afternoon.
On February 16, 2026, an incident identified as INC-262 occurred, resulting in a critical network outage that affected all systems in our Frankfurt data centers for a duration of 8 minutes. The incident was triggered by a routine configuration change made to a static route on one of our routers. Prior to implementation, the configuration underwent validation via the operating system \(Juniper Junos OS\), which generally checks for errors. However, due to a bug in the firmware, the system incorrectly accepted a faulty configuration change. 4 minutes after the change was applied, both forwarding engines were reported unreachable by the routing engine. The issue was promptly detected and reported by our monitoring systems. An automatic rollback occurred one minute following the failure due to a lack of manual confirmation, which restored both routing engines and forwarding engines. Safety mechanisms have worked as expected and resulted in a quick recovery completed by 7:27 PM. To preemptively harden our infrastructure against similar issues in the future, we already planned to transition from a redundant routing chassis to completely isolated devices, ensuring full redundancy even in case of such failures. This transition is scheduled for April/May during a planned maintenance. We appreciate your understanding and patience as we work to enhance our systems' reliability.
At 1:28PM the connection between our locations in Frankfurt and Zurich become degraded since one gateway at our upstreams becomes unavailable. The issue was resolved by 1:49PM completely by changing the gateway's configuration and adapting to the new configuration. Moving forward, we will check for possible improvements to enhance network resilience.
Pingoru polls LUMASERV's status page every 5 minutes and alerts you the moment it reports an issue — before your customers do.
5 free monitors · No credit card required