Subscribe to UpdatesSubscribe
Get email notifications whenever dataforest creates, updates or resolves an incident.
Get text message notifications whenever dataforest creates or resolves an incident.
Get incident updates and maintenance status messages in Slack.
Subscribe via Slack
By subscribing you acknowledge our Privacy Policy. In addition, you agree to the Atlassian Cloud Terms of Service and acknowledge Atlassian's Privacy Policy.
Get incident updates and maintenance status messages in Microsoft Teams channel.
By subscribing you acknowledge our Privacy Policy. In addition, you agree to the Atlassian Cloud Terms of Service and acknowledge Atlassian's Privacy Policy.
Get webhook notifications whenever dataforest creates an incident, updates an incident, resolves an incident or changes a component status.
Visit our support site.
All Systems Operational
Uptime over the past 90 days. View historical uptime.
dataforest Network
Operational
90 days ago
100.0
% uptime
Today
Edge Network (affects all locations)
Operational
90 days ago
100.0
% uptime
Today
DDoS Protection (affects all locations)
Operational
90 days ago
100.0
% uptime
Today
Dedicated Servers (EQX-FR4 & DRT-FRA8)
Operational
90 days ago
100.0
% uptime
Today
Datacenter MC-FRA01
Operational
90 days ago
99.99
% uptime
Today
Datacenter Core Routing & Switching
Operational
90 days ago
100.0
% uptime
Today
Ceph Cluster
Operational
90 days ago
100.0
% uptime
Today
Virtual Servers
Operational
90 days ago
99.98
% uptime
Today
Dedicated Servers
Operational
90 days ago
100.0
% uptime
Today
Plesk Web Hosting
Operational
90 days ago
99.99
% uptime
Today
TeamSpeak3 Servers
Operational
90 days ago
100.0
% uptime
Today
Network Storage
Operational
90 days ago
100.0
% uptime
Today
Facilites
Operational
90 days ago
100.0
% uptime
Today
Datacenter FC-FRA4
Operational
90 days ago
100.0
% uptime
Today
Datacenter Core Routing & Switching
Operational
90 days ago
100.0
% uptime
Today
Dedicated Servers
Operational
90 days ago
100.0
% uptime
Today
Facilites
Operational
90 days ago
100.0
% uptime
Today
General Services
Operational
90 days ago
100.0
% uptime
Today
Avoro CP & Support
Operational
90 days ago
100.0
% uptime
Today
PHP-Friends CRM & Support
Operational
90 days ago
100.0
% uptime
Today
Hotline
Operational
90 days ago
100.0
% uptime
Today
Dedicated Control Panel
Operational
90 days ago
100.0
% uptime
Today
IPMI VPN
Operational
90 days ago
100.0
% uptime
Today
DDoS Manager
Operational
90 days ago
100.0
% uptime
Today
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Major outage
Partial outage
No downtime recorded on this day.
No data exists for this day.
had a major outage.
had a partial outage.
Related
No incidents or maintenance related to this downtime.
Past Incidents
Aug 28, 2026
Completed -
The scheduled maintenance has been completed.
Aug 28, 04:44 CEST
Aug 28, 04:44 CEST
Verifying -
Phase 2 has been completed. Over the next few hours, we'll migrate remaining transit providers to the new router and take care of cleanup and documentation.
Aug 28, 02:49 CEST
Aug 28, 02:49 CEST
Update -
Phase 1 has been completed with less than one minute of downtime for local EQX-FR4 customers. We are now working on internal connectivity between EQX-FR4 and the rest of the dataforest network (Phase 2, BGP customers shall keep their sessions shut down).
Aug 28, 02:01 CEST
Aug 28, 02:01 CEST
Update -
Phase 1 has started.
Aug 28, 01:52 CEST
Aug 28, 01:52 CEST
Update -
Preparatory and validation work is complete. In 15 minutes, we will disconnect EQX-FR4 from dataforest's internal network, followed shortly thereafter by its disconnection from the internet. This will mark the start of Phase 1, as described previously.
Aug 28, 01:22 CEST
Aug 28, 01:22 CEST
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Aug 27, 22:00 CEST
Aug 27, 22:00 CEST
Scheduled -
On the night of August 27th to 28th, in the timeframe 22:00 - 07:00 (CEST), we are upgrading our PoP EQX-FR4.
We will replace our Juniper MX304 router with a new Juniper PTX10008, which will be our new standard platform for edge routers. This makes our backbone future-proof and allows us to significantly increase capacity at a PoP simply by adding line cards, without the need for further router replacements. Keep an eye on our Instagram, where we will share behind-the-scenes insights of the new hardware setup soon!
Who is affected:
Directly affected (downtime): All BGP, IP Transit, and dedicated server customers connected locally at EQX-FR4 (identifiable by the server's hostname).
Indirectly affected (no downtime): All other customers at all dataforest locations. You will experience no outage, but temporary reroutings will occur for some of our peering connections. Those can result in slightly increased latency, but we do not anticipate any outage as all traffic and DDoS protection is handled by our secondary PoP DRT-FRA8. Our backbone capacity is halved but always sufficient. As usual, a residual risk remains when working on critical backbone infrastructure even after intensive lab-testing of the new setup.
Maintenance schedule & impact for EQX-FR4:
• Phase 1 (30-60 minutes): Hard downtime for all local connections at EQX-FR4 during physical migration. Servers at this location will be unreachable.
• Phase 2 (30-60 minutes): General internet connectivity is restored. However, internal network connectivity from EQX-FR4 to the rest of the dataforest network will remain temporarily unavailable while routing protocols (iBGP/MPLS) are being migrated.
• Fallback Plan: In the highly unlikely event of a critical failure at our secondary PoP before the new PTX router is fully operational, we will immediately abort the migration and restore service via the existing MX router within ~30 minutes. The same goes for any production issues with the new router.
Customer action suggested (EQX-FR4 only):
• BGP & IP Transit: Please actively reroute upstream traffic away from your sessions for the entire maintenance window to avoid blackholing during Phase 2 or preparation work.
• High-Availability Workloads: We strongly recommend temporarily draining affected nodes from your global load balancing prior to the maintenance.
We will keep you updated here on the progress. Thank you for your cooperation!
Aug 24, 01:26 CEST
We will replace our Juniper MX304 router with a new Juniper PTX10008, which will be our new standard platform for edge routers. This makes our backbone future-proof and allows us to significantly increase capacity at a PoP simply by adding line cards, without the need for further router replacements. Keep an eye on our Instagram, where we will share behind-the-scenes insights of the new hardware setup soon!
Who is affected:
Directly affected (downtime): All BGP, IP Transit, and dedicated server customers connected locally at EQX-FR4 (identifiable by the server's hostname).
Indirectly affected (no downtime): All other customers at all dataforest locations. You will experience no outage, but temporary reroutings will occur for some of our peering connections. Those can result in slightly increased latency, but we do not anticipate any outage as all traffic and DDoS protection is handled by our secondary PoP DRT-FRA8. Our backbone capacity is halved but always sufficient. As usual, a residual risk remains when working on critical backbone infrastructure even after intensive lab-testing of the new setup.
Maintenance schedule & impact for EQX-FR4:
• Phase 1 (30-60 minutes): Hard downtime for all local connections at EQX-FR4 during physical migration. Servers at this location will be unreachable.
• Phase 2 (30-60 minutes): General internet connectivity is restored. However, internal network connectivity from EQX-FR4 to the rest of the dataforest network will remain temporarily unavailable while routing protocols (iBGP/MPLS) are being migrated.
• Fallback Plan: In the highly unlikely event of a critical failure at our secondary PoP before the new PTX router is fully operational, we will immediately abort the migration and restore service via the existing MX router within ~30 minutes. The same goes for any production issues with the new router.
Customer action suggested (EQX-FR4 only):
• BGP & IP Transit: Please actively reroute upstream traffic away from your sessions for the entire maintenance window to avoid blackholing during Phase 2 or preparation work.
• High-Availability Workloads: We strongly recommend temporarily draining affected nodes from your global load balancing prior to the maintenance.
We will keep you updated here on the progress. Thank you for your cooperation!
Aug 24, 01:26 CEST
Aug 27, 2026
Completed -
The scheduled maintenance has been completed.
Aug 27, 18:00 CEST
Aug 27, 18:00 CEST
Verifying -
We have successfully verified all servers and found no issues. All affected servers have now been back online for more than 30 minutes. The maintenance has therefore been completed well ahead of schedule.
If your server is not reachable, please verify your server's console output via IPMI in the Dedicated Server Control Panel and resolve any software-side issues that may prevent the system from booting. If you suspect a hardware fault, please contact our support team via ticket.
Aug 27, 16:02 CEST
If your server is not reachable, please verify your server's console output via IPMI in the Dedicated Server Control Panel and resolve any software-side issues that may prevent the system from booting. If you suspect a hardware fault, please contact our support team via ticket.
Aug 27, 16:02 CEST
Update -
All rack feeds were re-energized faster than planned, within approximately 5 minutes. No racks required servers to be powered on individually due to high inrush current.
The first affected servers are already back online. Any servers that do not power on on their own will be checked by us automatically. Please do not interfere with this process manually!
Aug 27, 15:31 CEST
The first affected servers are already back online. Any servers that do not power on on their own will be checked by us automatically. Please do not interfere with this process manually!
Aug 27, 15:31 CEST
Update -
Power on UV-O has been restored. We are now sequentially re-energizing all affected rack feeds, which is expected to take up to 30 minutes. Afterwards, we will report any racks that require servers to be powered on individually due to high inrush current.
Aug 27, 15:24 CEST
Aug 27, 15:24 CEST
Update -
UV-O is now off.
Aug 27, 13:35 CEST
Aug 27, 13:35 CEST
Update -
Final reminder: Single-PSU servers connected to UV-O must be shut down now.
Aug 27, 13:20 CEST
Aug 27, 13:20 CEST
In progress -
Preparatory work on the power sub-distribution is currently underway. The scheduled shutdown of UV-O has been moved to 13:30, and the timeline has been adjusted accordingly.
Reminder: Single-PSU servers connected to UV-O must be shut down cleanly before 13:30 CEST.
Aug 27, 11:52 CEST
Reminder: Single-PSU servers connected to UV-O must be shut down cleanly before 13:30 CEST.
Aug 27, 11:52 CEST
Scheduled -
On August 27, 2026, maintenance work will take place in the FC-FRA4 data center on power sub-distribution UV-O, which will be migrated to the new low-voltage main distribution (NSHV-B) in the process. This measure is part of the step-by-step modernization of the power supply at the site. In the target state, every dataforest rack will be supplied via NSHV-A and NSHV-B, each equipped with its own UPS and emergency power generator system, which further increases redundancy.
Who is affected:
Some dedicated servers and colocation racks at the FC-FRA4 location are affected. Other locations are not affected.
For servers with redundant power supplies (according to contract / product description), no outage is expected. If these are located in affected racks, only one power feed will drop out. Depending on CPU and load, a lower maximum clock speed is possible.
Servers with only one power supply connected to UV-O will be without power during the maintenance and must be cleanly shut down by you beforehand to prevent data loss and file system damage. We will shut down affected Managed Dedicated Servers.
How to check if your server is affected:
Check your server's current name at https://dedicated.dataforest.cloud. If your server carries the suffix "-UV-O", for example "root1234.fc-fra4-UV-O", it is directly affected. Please note that there are also other sub-distribution suffixes that have nothing to do with this maintenance.
Maintenance schedule (CEST):
• Morning: Multi-hour preparation of the new supply line from NSHV-B to UV-O.
• 13:30: Scheduled shutdown of UV-O.
• 15:30: Power restoration of UV-O and sequential energizing of all rack feeds including functionality check.
• 16:00: Expected completion of feed energization.
• until approx. 16:30: Buffer for racks with high inrush current (step-by-step "server-by-server" switching on may be required). We will inform you here continuously about affected racks.
• 16:30 – 17:30: On-site inspection of servers that did not power on automatically.
You must shut down affected servers yourself prior to 13:00. Otherwise, they will be hard switched off by the power shutdown.
Servers start automatically with our standard BIOS configuration after power supply is restored. Servers that do not switch on automatically will be checked by our technicians independently and immediately. Please do not intervene manually in this process!
The maintenance window serves as a guideline. Work on the power supply is subject to strict safety precautions: Before switching over, the new supply line will be extensively electrically tested (including insulation and impedance measurement, testing of the clockwise rotating field, and phase position control). Personnel safety takes precedence over schedule adherence at all times. We will inform you here about the progress of the work and any deviations.
Which racks are affected:
Dedicated Server Racks:
X06, X12, Y01, Y02, Y03, Y04, Y05, Y06, Y07, Y08, Y10, Y11, Y12
Colocation / Customer Racks:
X17, Y13, Y14, Y15
Additionally, for the duration of the maintenance work, there is no power redundancy for the core switching of rack rows Y and Z. Network operation in rack row X is unaffected by this.
You can assign your server's rack using the switch port statistics. For customer racks, we have no knowledge about the power redundancy of the connected servers. Colocation customers must explicitly connect redundant servers to PDUs of different sub-distribution boards.
How you should prepare:
• Subscribe to this status page for live updates.
• Check if your server is connected to "-UV-O".
• Plan the shutdown and downtime if necessary.
• Inform your users or customers.
• If possible, perform a test reboot in advance and check whether all required services start automatically.
• Check via IPMI whether "Restore on AC Power Loss -> Power On" is set in the BIOS (dataforest standard). Our support will carry out this check upon request until August 26, 2026.
• Check RAID and backups and create a full backup before the maintenance.
If your server is not reachable after the maintenance:
First check this status post. Is the maintenance completed and no problem reported for your rack? Then please check the screen output via IPMI in the control panel and resolve any software problems that prevent starting. If you suspect a hardware defect, contact our support via ticket system.
How dataforest is prepared:
• Top-of-rack switches are redundantly connected to power and network. Even with only one booked uplink, your switch has two power feeds and two core switch uplinks ("double redundancy").
• Our on-site spare parts warehouse is being stocked up to resolve potential defects quickly.
• dataforest employees are on site and coordinate the work directly with the service providers.
• Redundant power supplies were checked in advance.
Thank you for your assistance.
Aug 19, 01:41 CEST
Who is affected:
Some dedicated servers and colocation racks at the FC-FRA4 location are affected. Other locations are not affected.
For servers with redundant power supplies (according to contract / product description), no outage is expected. If these are located in affected racks, only one power feed will drop out. Depending on CPU and load, a lower maximum clock speed is possible.
Servers with only one power supply connected to UV-O will be without power during the maintenance and must be cleanly shut down by you beforehand to prevent data loss and file system damage. We will shut down affected Managed Dedicated Servers.
How to check if your server is affected:
Check your server's current name at https://dedicated.dataforest.cloud. If your server carries the suffix "-UV-O", for example "root1234.fc-fra4-UV-O", it is directly affected. Please note that there are also other sub-distribution suffixes that have nothing to do with this maintenance.
Maintenance schedule (CEST):
• Morning: Multi-hour preparation of the new supply line from NSHV-B to UV-O.
• 13:30: Scheduled shutdown of UV-O.
• 15:30: Power restoration of UV-O and sequential energizing of all rack feeds including functionality check.
• 16:00: Expected completion of feed energization.
• until approx. 16:30: Buffer for racks with high inrush current (step-by-step "server-by-server" switching on may be required). We will inform you here continuously about affected racks.
• 16:30 – 17:30: On-site inspection of servers that did not power on automatically.
You must shut down affected servers yourself prior to 13:00. Otherwise, they will be hard switched off by the power shutdown.
Servers start automatically with our standard BIOS configuration after power supply is restored. Servers that do not switch on automatically will be checked by our technicians independently and immediately. Please do not intervene manually in this process!
The maintenance window serves as a guideline. Work on the power supply is subject to strict safety precautions: Before switching over, the new supply line will be extensively electrically tested (including insulation and impedance measurement, testing of the clockwise rotating field, and phase position control). Personnel safety takes precedence over schedule adherence at all times. We will inform you here about the progress of the work and any deviations.
Which racks are affected:
Dedicated Server Racks:
X06, X12, Y01, Y02, Y03, Y04, Y05, Y06, Y07, Y08, Y10, Y11, Y12
Colocation / Customer Racks:
X17, Y13, Y14, Y15
Additionally, for the duration of the maintenance work, there is no power redundancy for the core switching of rack rows Y and Z. Network operation in rack row X is unaffected by this.
You can assign your server's rack using the switch port statistics. For customer racks, we have no knowledge about the power redundancy of the connected servers. Colocation customers must explicitly connect redundant servers to PDUs of different sub-distribution boards.
How you should prepare:
• Subscribe to this status page for live updates.
• Check if your server is connected to "-UV-O".
• Plan the shutdown and downtime if necessary.
• Inform your users or customers.
• If possible, perform a test reboot in advance and check whether all required services start automatically.
• Check via IPMI whether "Restore on AC Power Loss -> Power On" is set in the BIOS (dataforest standard). Our support will carry out this check upon request until August 26, 2026.
• Check RAID and backups and create a full backup before the maintenance.
If your server is not reachable after the maintenance:
First check this status post. Is the maintenance completed and no problem reported for your rack? Then please check the screen output via IPMI in the control panel and resolve any software problems that prevent starting. If you suspect a hardware defect, contact our support via ticket system.
How dataforest is prepared:
• Top-of-rack switches are redundantly connected to power and network. Even with only one booked uplink, your switch has two power feeds and two core switch uplinks ("double redundancy").
• Our on-site spare parts warehouse is being stocked up to resolve potential defects quickly.
• dataforest employees are on site and coordinate the work directly with the service providers.
• Redundant power supplies were checked in advance.
Thank you for your assistance.
Aug 19, 01:41 CEST
Completed -
The scheduled maintenance has been completed.
Aug 27, 03:00 CEST
Aug 27, 03:00 CEST
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Aug 26, 23:00 CEST
Aug 26, 23:00 CEST
Scheduled -
The internet exchange DE-CIX has announced maintenance on its Frankfurt peering platform.
When our own port is affected by such maintenance, we gracefully reroute the affected traffic in advance. Our port is not affected by this maintenance, so no action is required from our side.
Please note: DE-CIX Frankfurt is one of the world's largest internet exchanges. Other networks affected by the maintenance may not reroute their traffic in advance, potentially causing connectivity issues on paths to or from dataforest even though our own network remains fully operational.
We have seen this during previous DE-CIX maintenance windows and publish this notice as a precaution. Such issues occur outside our control and cannot be prevented or resolved by us.
Aug 26, 22:38 CEST
When our own port is affected by such maintenance, we gracefully reroute the affected traffic in advance. Our port is not affected by this maintenance, so no action is required from our side.
Please note: DE-CIX Frankfurt is one of the world's largest internet exchanges. Other networks affected by the maintenance may not reroute their traffic in advance, potentially causing connectivity issues on paths to or from dataforest even though our own network remains fully operational.
We have seen this during previous DE-CIX maintenance windows and publish this notice as a precaution. Such issues occur outside our control and cannot be prevented or resolved by us.
Aug 26, 22:38 CEST
Aug 26, 2026
Completed -
The scheduled maintenance has been completed.
Aug 26, 05:00 CEST
Aug 26, 05:00 CEST
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Aug 25, 23:00 CEST
Aug 25, 23:00 CEST
Scheduled -
The internet exchange DE-CIX has announced maintenance on its Frankfurt peering platform, directly affecting our port at DE-CIX Frankfurt.
Beforehand, we will gracefully reroute traffic that would normally be exchanged via DE-CIX Frankfurt to other peering platforms (MegaIX and ERA-IX) or transit providers.
This may result in slightly increased latency on some paths, but we do not expect any outage.
Please note: DE-CIX Frankfurt is one of the world's largest internet exchanges. While we will reroute our traffic in advance, other networks may not do so, potentially causing connectivity issues outside our control. We have seen this during previous DE-CIX maintenance windows and cannot prevent or resolve such issues ourselves.
Aug 25, 22:53 CEST
Beforehand, we will gracefully reroute traffic that would normally be exchanged via DE-CIX Frankfurt to other peering platforms (MegaIX and ERA-IX) or transit providers.
This may result in slightly increased latency on some paths, but we do not expect any outage.
Please note: DE-CIX Frankfurt is one of the world's largest internet exchanges. While we will reroute our traffic in advance, other networks may not do so, potentially causing connectivity issues outside our control. We have seen this during previous DE-CIX maintenance windows and cannot prevent or resolve such issues ourselves.
Aug 25, 22:53 CEST
Aug 25, 2026
Aug 24, 2026
No incidents reported.
Aug 23, 2026
No incidents reported.
Aug 22, 2026
No incidents reported.
Aug 21, 2026
No incidents reported.
Aug 20, 2026
No incidents reported.
Aug 19, 2026
Completed -
The scheduled maintenance has been completed.
Aug 19, 16:30 CEST
Aug 19, 16:30 CEST
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Aug 19, 15:30 CEST
Aug 19, 15:30 CEST
Scheduled -
We will carry out maintenance on our DDoS protection infrastructure.
What we are doing
We will deploy software updates to our redundant DDoS scrubbing cluster. Filter appliances will be taken out of production and updated one by one to ensure mitigation capacity is always sufficient. After each update, functionality will be verified before we move on to the next filter.
Expected impact
No customer impact is expected at any datacenter, but it cannot be ruled out entirely. Idle (inactive) connections/sessions may time out; active ones should not, as they are synchronized during the startup of a new software release. If you notice anything unusual, such as timeouts of active sessions or the inability to connect to your server, please contact our support.
Affected customers
All IP prefixes routed through our DDoS protection (which is the default) are affected by this maintenance. Only prefixes that have been explicitly configured to bypass our DDoS protection (which we do not recommend) are unaffected. In any case, no customer action is required.
Fallback plan
Should the update fail and cause issues, we will disconnect the filters within a few seconds and update this status post transparently. In that case, mitigation of sophisticated attacks will not be possible for 30-60 minutes.
Aug 18, 16:05 CEST
What we are doing
We will deploy software updates to our redundant DDoS scrubbing cluster. Filter appliances will be taken out of production and updated one by one to ensure mitigation capacity is always sufficient. After each update, functionality will be verified before we move on to the next filter.
Expected impact
No customer impact is expected at any datacenter, but it cannot be ruled out entirely. Idle (inactive) connections/sessions may time out; active ones should not, as they are synchronized during the startup of a new software release. If you notice anything unusual, such as timeouts of active sessions or the inability to connect to your server, please contact our support.
Affected customers
All IP prefixes routed through our DDoS protection (which is the default) are affected by this maintenance. Only prefixes that have been explicitly configured to bypass our DDoS protection (which we do not recommend) are unaffected. In any case, no customer action is required.
Fallback plan
Should the update fail and cause issues, we will disconnect the filters within a few seconds and update this status post transparently. In that case, mitigation of sophisticated attacks will not be possible for 30-60 minutes.
Aug 18, 16:05 CEST
Aug 18, 2026
No incidents reported.
Aug 17, 2026
Completed -
The scheduled maintenance has been completed.
Aug 17, 16:00 CEST
Aug 17, 16:00 CEST
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Aug 17, 15:00 CEST
Aug 17, 15:00 CEST
Scheduled -
We will carry out maintenance on our DDoS protection infrastructure.
What we are doing
We will deploy software updates to our redundant DDoS scrubbing cluster. Filter appliances will be taken out of production and updated one by one to ensure mitigation capacity is always sufficient. After each update, functionality will be verified before we move on to the next filter.
Expected impact
No customer impact is expected at any datacenter, but it cannot be ruled out entirely. Idle (inactive) connections/sessions may time out; active ones should not, as they are synchronized during the startup of a new software release. If you notice anything unusual, such as timeouts of active sessions or the inability to connect to your server, please contact our support.
Affected customers
All IP prefixes routed through our DDoS protection (which is the default) are affected by this maintenance. Only prefixes that have been explicitly configured to bypass our DDoS protection (which we do not recommend) are unaffected. In any case, no customer action is required.
Fallback plan
Should the update fail and cause issues, we will disconnect the filters within a few seconds and update this status post transparently. In that case, mitigation of sophisticated attacks will not be possible for 30-60 minutes.
Aug 16, 17:02 CEST
What we are doing
We will deploy software updates to our redundant DDoS scrubbing cluster. Filter appliances will be taken out of production and updated one by one to ensure mitigation capacity is always sufficient. After each update, functionality will be verified before we move on to the next filter.
Expected impact
No customer impact is expected at any datacenter, but it cannot be ruled out entirely. Idle (inactive) connections/sessions may time out; active ones should not, as they are synchronized during the startup of a new software release. If you notice anything unusual, such as timeouts of active sessions or the inability to connect to your server, please contact our support.
Affected customers
All IP prefixes routed through our DDoS protection (which is the default) are affected by this maintenance. Only prefixes that have been explicitly configured to bypass our DDoS protection (which we do not recommend) are unaffected. In any case, no customer action is required.
Fallback plan
Should the update fail and cause issues, we will disconnect the filters within a few seconds and update this status post transparently. In that case, mitigation of sophisticated attacks will not be possible for 30-60 minutes.
Aug 16, 17:02 CEST
Resolved -
Yesterday morning at 10:33, our on-call engineer was alerted to increased latency at our FC-FRA4 location. Initial analysis suggested a false positive, as the issue affected specific network paths to the datacenter rather than all routes. After additional alerts for brief packet loss arose, our engineer escalated the incident to our NOC at 10:48.
A partially mitigated carpet-bombing DDoS attack was identified as the root cause, and this status post was published at 10:58. Full mitigation was active by 11:02.
Root Cause & Impact
Traffic flowing from our EQX-FR4 PoP to FC-FRA4 experienced link congestion. Traffic via DRT-FRA8 was unaffected because the attack was properly filtered at that site. Consequently, approximately 50% of incoming routes were impacted by brief packet loss and latency spikes.
Next Steps
Following today's internal review, we are implementing both technical and administrative improvements:
• Mitigation Bypasses: Implementing additional measures to prevent attack traffic from reaching the datacenter when real-time mitigation fails.
• Escalation Process: Refining internal procedures to accelerate incident handling.
Aug 17, 14:22 CEST
A partially mitigated carpet-bombing DDoS attack was identified as the root cause, and this status post was published at 10:58. Full mitigation was active by 11:02.
Root Cause & Impact
Traffic flowing from our EQX-FR4 PoP to FC-FRA4 experienced link congestion. Traffic via DRT-FRA8 was unaffected because the attack was properly filtered at that site. Consequently, approximately 50% of incoming routes were impacted by brief packet loss and latency spikes.
Next Steps
Following today's internal review, we are implementing both technical and administrative improvements:
• Mitigation Bypasses: Implementing additional measures to prevent attack traffic from reaching the datacenter when real-time mitigation fails.
• Escalation Process: Refining internal procedures to accelerate incident handling.
Aug 17, 14:22 CEST
Monitoring -
A fix has been implemented and we are monitoring the results.
Aug 16, 11:02 CEST
Aug 16, 11:02 CEST
Investigating -
We are currently investigating this issue.
Aug 16, 10:33 CEST
Aug 16, 10:33 CEST
Aug 16, 2026
Completed -
Our backbone failover test was successfully completed.
Metrics & Details:
• Dry-Runs: Successful pre-validation performed on non-production traffic in advance
• Cuts: Exactly 5 cuts on 5 dark fiber links executed cleanly without re-tests (04:24, 04:54, 05:20, 05:35, 05:56)
• Convergence: Minor packet loss between 27-30 seconds per cut → well within expected window; no unexpected outages in our network (e.g., BGP flaps) occurred
All dark fiber paths are back to normal operation.
Aug 16, 06:26 CEST
Metrics & Details:
• Dry-Runs: Successful pre-validation performed on non-production traffic in advance
• Cuts: Exactly 5 cuts on 5 dark fiber links executed cleanly without re-tests (04:24, 04:54, 05:20, 05:35, 05:56)
• Convergence: Minor packet loss between 27-30 seconds per cut → well within expected window; no unexpected outages in our network (e.g., BGP flaps) occurred
All dark fiber paths are back to normal operation.
Aug 16, 06:26 CEST
In progress -
Scheduled maintenance is currently in progress. We will provide updates as necessary.
Aug 16, 02:00 CEST
Aug 16, 02:00 CEST
Scheduled -
To ensure maximum resilience, we are conducting a series of controlled fiber failover simulations across our network to validate our modernized backbone architecture.
Following extensive lab testing, this maintenance serves as the final real-world validation of all routing protocols and convergence behaviors during physical link failures.
Scope & Expected Behavior
• Affected Services: All dataforest locations and products.
• Network Behavior: This is not a total network outage. Cuts are executed sequentially across our various dark fiber links, affecting only individual paths at a time.
• Traffic Rerouting: Per cut event, affected external paths are expected to experience a short packet loss / rerouting window of approximately 20 to 60 seconds.
• Internal Traffic: Network connectivity within the same datacenter is completely unaffected. Traffic flowing between different dataforest locations (e.g., cross-site backups) will experience the same temporary rerouting behavior as external traffic.
Execution & Safety Measures
• Phased Rollout: Testing will follow a strict, phased execution strategy to minimize customer impact: initial dry runs on non-productive traffic → graceful software-initiated cuts (which are expected to cause no packet loss at all but come with a residual risk) → physical fiber disconnects.
• Multiple Events: Each of our dark fibers will be tested sequentially in multiple iterations (both graceful and physical).
• Operational Focus: During the active test procedure, engineering focus remains 100% on execution, monitoring, and immediate remediation if unexpected behavior occurs. Live status updates will be paused during active cut windows; a comprehensive closing update will be published upon completion of the test suite.
• Objective: Proactively validating these failover scenarios under controlled conditions ensures that our network redundancy operates within expected timeframes during actual emergencies.
Customer Action Suggested
• BGP & IP Transit Customers: Please actively reroute your upstream traffic away from dataforest for the duration of the maintenance window to avoid rerouting delays.
• Multi-Location & High-Availability Workloads: If your infrastructure permits draining a location or temporarily removing dataforest nodes from global load balancing pools, we strongly recommend doing so prior to the test window.
Aug 9, 13:40 CEST
Following extensive lab testing, this maintenance serves as the final real-world validation of all routing protocols and convergence behaviors during physical link failures.
Scope & Expected Behavior
• Affected Services: All dataforest locations and products.
• Network Behavior: This is not a total network outage. Cuts are executed sequentially across our various dark fiber links, affecting only individual paths at a time.
• Traffic Rerouting: Per cut event, affected external paths are expected to experience a short packet loss / rerouting window of approximately 20 to 60 seconds.
• Internal Traffic: Network connectivity within the same datacenter is completely unaffected. Traffic flowing between different dataforest locations (e.g., cross-site backups) will experience the same temporary rerouting behavior as external traffic.
Execution & Safety Measures
• Phased Rollout: Testing will follow a strict, phased execution strategy to minimize customer impact: initial dry runs on non-productive traffic → graceful software-initiated cuts (which are expected to cause no packet loss at all but come with a residual risk) → physical fiber disconnects.
• Multiple Events: Each of our dark fibers will be tested sequentially in multiple iterations (both graceful and physical).
• Operational Focus: During the active test procedure, engineering focus remains 100% on execution, monitoring, and immediate remediation if unexpected behavior occurs. Live status updates will be paused during active cut windows; a comprehensive closing update will be published upon completion of the test suite.
• Objective: Proactively validating these failover scenarios under controlled conditions ensures that our network redundancy operates within expected timeframes during actual emergencies.
Customer Action Suggested
• BGP & IP Transit Customers: Please actively reroute your upstream traffic away from dataforest for the duration of the maintenance window to avoid rerouting delays.
• Multi-Location & High-Availability Workloads: If your infrastructure permits draining a location or temporarily removing dataforest nodes from global load balancing pools, we strongly recommend doing so prior to the test window.
Aug 9, 13:40 CEST
Aug 15, 2026
Resolved -
The cooling outage at EQX-FR5 has been resolved, and GTT has brought their infrastructure fully back online. Over the past few hours, all of our 400G ports with GTT at EQX-FR4 sequentially recovered and returned to normal operation.
Throughout the entire event, our redundant backbone architecture and automatic failover performed exactly as designed, absorbing the link losses without customer-facing impact.
Aug 15, 18:56 CEST
Throughout the entire event, our redundant backbone architecture and automatic failover performed exactly as designed, absorbing the link losses without customer-facing impact.
Aug 15, 18:56 CEST
Identified -
We want to inform our customers about an ongoing incident with one of our transit providers, GTT Communications, which is currently not causing a negative impact on our network. In accordance with our communication standards, we decided to still publish it as a precautionary measure.
At 05:19, our NOC was alerted that one of our 400G ports with GTT was down at our EQX-FR4 location. During diagnosis, we found the issue to be on GTT's side and created a ticket with their NOC. Right after creation, at 05:51, a second 400G port went offline. Neither outage caused any visible disruption according to our real-time network overview, as convergence happens almost instantly if a router port goes down physically.
At 06:36, the GTT NOC claimed that the issue was outside of their network and advised us to check our cross-connects with the datacenter operator (Equinix).
At 06:56, the two remaining 400G ports we have with GTT at EQX-FR4 went down, causing about 15 seconds of packet loss on a few routes because the ports failed simultaneously and GTT traffic shifted automatically to our second PoP at DRT-FRA8. We escalated the matter to GTT immediately, but did not receive feedback for several hours.
At 11:21, we were informed that the reason for the outage is an ongoing cooling system failure at EQX-FR5, where two water leaks had been detected and isolated.
Please be aware that this does not affect our EQX PoP directly, as the FR4 datacenter is unaffected. Temperatures were already checked manually overnight and found to be optimal.
For the time being, the situation is as follows:
- Our GTT ports at DRT-FRA8 are still working. We always operate our transit ports at both PoPs. Other transit providers (Tata, NTT) are unaffected.
- Our transit capacity is reduced from 4.8 Tbps to 3.2 Tbps, which is still more than sufficient even for large-scale DDoS attacks. Also, multiple Tbps of peering capacity are entirely unaffected. However, depending on the distribution of individual attacks, short-term bottlenecks are possible on single links.
- As traffic to and from GTT is routed via DRT-FRA8, we are experiencing an (expected) imbalance on internal backbone links between our datacenters. We are closely monitoring all load parameters and will take action if needed.
- As various network operators are affected by this issue, customers might see slightly increased latencies. This is not necessarily an issue within our control, but our support team is happy to check if you notice anything unusual.
Once the GTT ports recover, traffic will automatically shift back to our EQX-FR4 PoP. This can cause brief reconnects for existing TCP and UDP sessions on IP addresses with active DDoS protection.
Aug 15, 13:00 CEST
At 05:19, our NOC was alerted that one of our 400G ports with GTT was down at our EQX-FR4 location. During diagnosis, we found the issue to be on GTT's side and created a ticket with their NOC. Right after creation, at 05:51, a second 400G port went offline. Neither outage caused any visible disruption according to our real-time network overview, as convergence happens almost instantly if a router port goes down physically.
At 06:36, the GTT NOC claimed that the issue was outside of their network and advised us to check our cross-connects with the datacenter operator (Equinix).
At 06:56, the two remaining 400G ports we have with GTT at EQX-FR4 went down, causing about 15 seconds of packet loss on a few routes because the ports failed simultaneously and GTT traffic shifted automatically to our second PoP at DRT-FRA8. We escalated the matter to GTT immediately, but did not receive feedback for several hours.
At 11:21, we were informed that the reason for the outage is an ongoing cooling system failure at EQX-FR5, where two water leaks had been detected and isolated.
Please be aware that this does not affect our EQX PoP directly, as the FR4 datacenter is unaffected. Temperatures were already checked manually overnight and found to be optimal.
For the time being, the situation is as follows:
- Our GTT ports at DRT-FRA8 are still working. We always operate our transit ports at both PoPs. Other transit providers (Tata, NTT) are unaffected.
- Our transit capacity is reduced from 4.8 Tbps to 3.2 Tbps, which is still more than sufficient even for large-scale DDoS attacks. Also, multiple Tbps of peering capacity are entirely unaffected. However, depending on the distribution of individual attacks, short-term bottlenecks are possible on single links.
- As traffic to and from GTT is routed via DRT-FRA8, we are experiencing an (expected) imbalance on internal backbone links between our datacenters. We are closely monitoring all load parameters and will take action if needed.
- As various network operators are affected by this issue, customers might see slightly increased latencies. This is not necessarily an issue within our control, but our support team is happy to check if you notice anything unusual.
Once the GTT ports recover, traffic will automatically shift back to our EQX-FR4 PoP. This can cause brief reconnects for existing TCP and UDP sessions on IP addresses with active DDoS protection.
Aug 15, 13:00 CEST
Aug 14, 2026
No incidents reported.