On 5 November 2026, from 18:37 CET, a distributed denial-of-service (DDoS) attack hit our Hamburg network. At its peak, the attack sent 10.16 Gbit/s and 1.57 million packets per second to one of our IP addresses. This filled the 10 Gbit/s uplink of the location. The website, the API, and the dashboard were down or unreliable for several hours. A second attack on the website followed later in the evening. All services were fully reachable again at about 07:15 CET on 6 November. No stored backup data was lost.
This report explains what happened, what was affected, and what we change. All times are CET.
- A UDP flood of up to 10.16 Gbit/s filled the uplink of our Hamburg network from 19:00 CET.
- The website, the API, and the dashboard were down or unreliable from 18:37 CET. Full access came back at about 07:15 CET on 6 November.
- No stored backup data was lost. Datastores and buckets kept their data during the whole incident.
- 42 payment events from Stripe arrived late. We replayed all of them on 6 November at 07:16 CET.
- The website now runs behind a CDN. We add more filters at our routers and move the API and the dashboard behind DDoS protection.
What Happened
The API, the dashboard, and the website run on one platform in our Hamburg rack. The rack connects to the internet through one 10 Gbit/s uplink to our upstream provider.
At 18:37, a first short burst of traffic arrived. At 19:00, the real attack started. It was a UDP flood to port 80 of the public IP address of our platform. A sample of the traffic showed about 700 source addresses and packets of 940 to 1390 bytes. Our routers could process the packets, but the uplink itself was full. When a link is full, our own filters cannot help: the good traffic is lost before it reaches them.
The result was 75 to 100% packet loss for everything in the Hamburg rack. Our BGP sessions to the upstream provider went down and up again many times, which made the problem worse for a short time.
At about 19:55, the flood fell to about 1.8 Gbit/s. With room on the link again, a drop rule on both of our routers removed the attack traffic, and the services came back.
The Second Attack
At about 21:20, a second attack started. This time it was an HTTP/2 flood on the website, with a very high rate of normal-looking page requests. It overloaded the reverse proxy of our platform, and the proxy restarted every one to two minutes. This also took the API and the dashboard down, because they use the same proxy.
To stop it, we moved the website behind a CDN with bot protection. Then we told our routers to accept web traffic to the platform only from the CDN and from our own systems.
The API and the dashboard do not run behind the CDN yet. The filter therefore also blocked customers from the API and the dashboard until we removed it at about 07:15 CET on 6 November. Backup and restore traffic does not use the API, but you could not log in to the dashboard or change your services in this time.
DDoS Scrubbing
In the evening, our upstream provider moved the traffic for our Hamburg network through a DDoS scrubbing service. More attack waves of up to 913,000 packets per second came in until about 23:22. The scrubbing service filtered most of them, and the rest stopped at our routers. Since 23:22, we have seen no more attack traffic.
The scrubbing service had one side effect. It also dropped the replies to connections that our platform opened to other services. This affected our payment provider and our accounting system. We sent this traffic through other paths, so payments worked again from about 00:10.
What Was Affected
- Website: down or unreliable from 18:37 to about 19:55, and again from about 21:20 until it moved behind the CDN later that evening.
- API and dashboard: down or unreliable from 18:37 to about 19:55. From about 21:20 to about 07:15, they were down for customers, first because of the second attack and then because of our filter.
- Hamburg network: heavy packet loss from 18:37 to about 19:55. Backup jobs that went through our Hamburg network in this time could fail or run slowly.
- Payments: Stripe could not deliver 42 events (invoices, subscription changes, and payment results) between 19:01 on 5 November and 05:30 on 6 November. We replayed all of them on 6 November at 07:16. Invoice and payment status changes from this time appeared late in your account.
What was not affected:
- Stored data. No datastore, bucket, or snapshot lost data. The attack targeted the network, not the storage.
Look at the backup job logs for the evening of 5 November. If a job failed between 18:37 and 20:00 CET, run it again or wait for the next scheduled run. If an invoice or a payment status in your dashboard looks wrong, contact support.
Timeline
First burst
The first short burst of attack traffic arrives.
UDP flood starts
The uplink is full.
Peak packet rate
1.57 million packets per second.
Peak bandwidth
10.16 Gbit/s.
Services come back
The flood falls to about 1.8 Gbit/s. A drop rule on our routers removes it.
Second attack
An HTTP/2 flood on the website. The reverse proxy restarts every 1 to 2 minutes.
CDN and scrubbing
The website moves behind a CDN. Our routers accept web traffic only from the CDN and our own systems. Our upstream provider routes our traffic through a DDoS scrubbing service.
Last attack wave ends
Payments work again
Traffic to our payment provider goes through another network path.
Full access
We remove the web filter. The API and the dashboard are reachable for all customers again.
Payment events replayed
We replay the 42 Stripe events that were not delivered. All are processed.
What We Change
Filters at our routers. The drop rules from that evening stay active. We add a default rule set for UDP traffic that our platform does not use, so the next flood on a different port also stops at our routers. Router filters only help while the link has free capacity, so this is one part of the protection, not all of it.
Upstream protection. We work with our upstream provider on fixed filter rules for known attack traffic and on a blackhole function. With a blackhole, the upstream provider drops traffic to one IP address before it reaches our uplink.
API and dashboard behind DDoS protection. The website already runs behind the CDN. The API and the dashboard follow, so an attack on them cannot fill the uplink of the storage network. We also separate the public endpoints from the network of our storage systems.
Better monitoring. We now graph the packet rate of the uplink and alert on it. During the incident, our monitoring showed the full link but not the packet rate, which made the first diagnosis slower.
Payment events. We now check for undelivered payment events after every network incident, so invoices and payment results do not wait for the next automatic retry.
Wrapping Up
The attack filled our Hamburg uplink, and our platform was down or unreliable for several hours. Your stored backups were safe during the whole incident. We are sorry for the trouble this caused. The changes above make the next attack smaller and shorter. If you have questions about this incident or about your services, contact support.
