LUMASERV had 18 outages in the last 2 years totaling 28h 34m of downtime — averaging 0.7 incidents per month.
There were 18 LUMASERV outages since June 10, 2024 totaling 28h 34m of downtime. Each is summarised below — incident details, duration, and resolution information.
The DENIC is currently experiencing a major issue causing all .de Domains to become unresolvable after dns caches run out. DENIC Statuspage: https://status.denic.de/pages/incident/592577eab611ce1e0d00046f/69fa60ef9d12f5057a974f38
This incident has been resolved.
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.
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.
Starting this morning, we have detected packet loss occurring a few times for a few seconds at carrier level. Our analysis revealed that this is related to incoming or outgoing traffic via Liberty Global (AS6830). As a mitigation measure, we have deactivated this carrier and are using alternative routes. We will monitor the situation closely and wait for a response before reactivating the carrier.
One of our upstreams was experiencing network issues for about 5 minutes. Redundancy was working as expected and there was no noticeable impact.
A physical network connection inside our network in our FRA-2 location failed causing packet loss and a disturbance of multiple services. All our links are setup redundantly and the redundancy automatically took over within a few seconds.
One of our uplink providers, IP-Projects (AS48314), is experiencing a network attack. This have lead to packet loss for max. five minutes, starting from 11.42. We have deactivated incoming and outgoing till the network is stable again there. Link to our uplink's status page entry: https://status.ip-projects.de/?page=Issue&id=551
This incident has been resolved.
From 22 July 2025 10pm to 23 July 2025 1.30pm, some customers using our DDoS Protected IP-Transit service experienced connectivity issues during active DDoS mitigation. This was due to an incorrect routing configuration by one of our upstream providers. The incident affected IP addresses with active DDoS mitigations during the mitigation period for the attack (typically 30 minutes). The majority of our services remained operational throughout this period. We resolved the issue by extending our routing policies and working with our provider to prevent this configuration problem from recurring. We apologize for any inconvenience this may have caused.
We are seeing issues regarding routes to Cloudflare, we're investigating and will update you as soon as we have further information.
We identified that Cloudflare DNS has major issues, causing some servers using Cloudflare DNS to have dns resolution issues. This is not an issue on our side but we'll keep monitoring it.
We identified that Cloudflare DNS has major issues, causing some servers using Cloudflare DNS to have dns resolution issues. This is not an issue on our side but we'll keep monitoring it. Cloudflare has posted the incident on their statuspage: https://www.cloudflarestatus.com/incidents/28r0vbbxsh8f
We continuing to monitor
The incident has been resolved by Cloudflare
We're currently experiencing a major outage on our compute infrastructure in our FRA-2 location. We're investigating the issue and will provide additional information soon
We've identified the issue and are working on recovering all services ASAP
We are currently booting all affected servers again. The services will be back online in the next minutes.
We brought all services back up and are closely monitoring them
All services are running as expected again. We will keep monitoring and let the incident open till we publish an official statement tomorrow.
All systems and services have been stable since the recovery and the normal operational state has been fully recovered. The root cause was a power outage in one of our locations. We don't have information about the exact cause yet but are in contact with the datacenter provider to get more information about the incident. To ensure that a similar incident can be preempted or mitigated, we will do an internal review and inform you about our steps as soon as this has been completed.
One of our hypervisors became unavailable, we're currently investigating the issue
The hypervisor has been taken out of service and all services have been distributed to different hypervisors. We're closely monitoring the situation and we'll post postmortem once we have all information on what happened.
This incident has been resolved.
We are currently investigating
The issue has been mitigated, we continue to monitor and post an update once we have all information on what exactly happened
This incident has been resolved.
One of our uplink providers experienced a hardware failure resulting in an outage of that uplink. Our redundancy took over automatically but there was temporary packet loss noticeable during the switch-over phase.
Today at 18:47 CEST we had a hardware failure on our virtualization node ls-ds-46. After the problem could not be solved via IPMI, we migrated all VMs to other hosts and restarted them. By 19:24 at the latest, all VMs were completely restarted. The affected host was deactivated immediately and will be investigated and tested before being reactivated.
This incident has been resolved.