Alphavps driftsforstyrrelser

1. 30. juli 2026 kl. 12.50 UTCidentified

   Vi er begyndt forebyggende vedligeholdelse af hardware på følgende knudepunkter: SOFSTORAGE01 SOFSTORAGE06 SOFSTORAGE07 VPS tilfælde hostet på de berørte knudepunkter kan opleve en midlertidig afbrydelse. Den forventede nedetid er ca. 15 til 30 minutter pr. VPS. Vores team overvåger vedligeholdelsen nøje og vil levere yderligere opdateringer, efterhånden som arbejdet skrider frem.

2. 30. juli 2026 kl. 13.13 UTCidentified

   Vi begynder at arbejde på SOFSTORAGE07. VMs har været nådig lukning og vil blive sat op igen snart.

3. 30. juli 2026 kl. 13.25 UTCidentified

   Vi har afsluttet arbejdet med SOFSTORAGE07 og virtuelle maskiner starter op igen. Vi bevæger os fremad med SOFSTORAGE01, virtuelle maskiner er ved at blive nedlukning og vedligeholdelse begynder.

4. 30. juli 2026 kl. 14.00 UTCidentified

   Vi har afsluttet arbejdet med SOFSTORAGE01 og virtuelle maskiner starter op igen. Vi bevæger os fremad med SOFSTORAGE06, virtuelle maskiner bliver nedlukning og vedligeholdelse begynder.

5. 31. juli 2026 kl. 10.55 UTCidentified

   SOFSTORAGE06 vedligehold er færdig og alle VM starter op.

6. 21. august 2026 kl. 11.11 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. juni 2026 kl. 18.42 UTCidentified

   Vi oplever i øjeblikket et stort DDoS angreb rettet mod dele af vores netinfrastruktur. Dette angreb forårsager intermitterende forbindelse problemer og øget latency for nogle kunder. Vores netværk engineering team arbejder aktivt på at implementere yderligere permanente afbødende foranstaltninger til fuldt ud at løse dette angreb og yderligere styrke modstandsdygtigheden af vores infrastruktur. Der er allerede indført midlertidig afbødning, og vi fortsætter med at overvåge og tilpasse vores forsvar, efterhånden som angrebet udvikler sig. Vi undskylder oprigtigt for eventuelle forstyrrelser dette kan forårsage og værdsætter din tålmodighed, mens vi arbejder hen imod en komplet og permanent løsning. Der vil blive fremlagt yderligere opdateringer, efterhånden som der gøres fremskridt.

2. 29. juni 2026 kl. 19.39 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

3. 29. juni 2026 kl. 20.01 UTCidentified

   Vi har afbødet Nürnberg. Sofia er under behandling og bør anvendes inden længe. Da vi har at gøre med en afpresning / løsesum DDoS angreb, er vi ude af stand til at dele flere detaljer offentligt.

4. 29. juni 2026 kl. 21.22 UTCidentified

   Mens de ondsindede angribere konstant ændrer angrebsmønstre, vi anvender afbødning og de fleste af vores kunder er tilbage online. Vi engagerer os også i det lokale politi. Yderligere oplysninger at følge.

5. 30. juni 2026 kl. 00.52 UTCmonitoring

   Vi har gennemført afbødning på tværs af alle vores steder og trafikken er vendt tilbage til normal. Der kan være forskelle i ICMP, men vi har tillid til, at spørgsmålet bliver løst fuldt ud.

6. 30. juni 2026 kl. 07.30 UTCmonitoring

   Vi fortsætter med at overvåge situationen og foretage afbødende justeringer. Alle tjenester på tværs af alle steder er online og betragtes som stabile i øjeblikket.

7. 30. juni 2026 kl. 07.36 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

8. 30. juni 2026 kl. 16.38 UTCmonitoring

   Vi overvåger situationen og justeringsafbødningsprofilen på tværs af steder for at sikre problemfri arbejde af afbødende apparater med minimale afbrydelser.

9. 9. juli 2026 kl. 03.44 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 27. maj 2026 kl. 12.56 UTCidentified

   Vi har startet en hurtig netværksvedligeholdelse i vores placering i New York for at implementere nye opstrømsforbindelser efter den uventede exit af vores nuværende udbyder fra anlægget. Yderligere oplysninger sendes via e-mail til alle berørte virtuelle maskine kunder. Under denne vedligeholdelse, kan nogle kunder opleve intermitterende forbindelsesafbrydelser eller midlertidig nedetid, mens netværk migration aktiviteter udføres. Vedligeholdelsesvinduet forventes at vare op til 8 timer, selvom vi mener, at den faktiske afbrydelse vil være betydeligt kortere. Vi undskylder virkelig for den korte varsel og eventuelle ulemper forårsaget. Denne opgradering er et vigtigt skridt i retning af at forbedre den langsigtede stabilitet og kvaliteten af vores New York-tjenester. Yderligere opdateringer vil blive lagt her som fremskridt fortsætter.

2. 27. maj 2026 kl. 15.28 UTCmonitoring

   Vi er færdige med netværksopgraderingen og fra 1 time - alt netværk er stabilt. Vi fortsætter overvågningen et par timer mere, indtil vi lukker sagen.

3. 30. juni 2026 kl. 00.51 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. april 2026 kl. 09.31 UTCidentified

   En kritisk RAID array fiasko fandt sted på dalstorage01 tidligere i dag. RAID controller trådte en ustabil tilstand og fortsatte skrive operationer, som resulterede i korruption af flere KVM disk-billeder. Noden blev taget offline med det samme for at forhindre yderligere effekt. RAID controller er blevet erstattet og inddrivelsesprocedurer er i øjeblikket i gang. På grund af array størrelse, recovery er tidsintensiv og data konsistens kan ikke garanteres. På nuværende tidspunkt er ledig kapacitet i Dallas begrænset. Vi arbejder aktivt på at anvende yderligere hardware, men en præcis ETA er endnu ikke bekræftet. Berørte kunder forsynes med erstatningsydelser på alternative steder. Rescue adgang kan aktiveres på anmodning for bedste indsats data opsving. Yderligere opdateringer vil blive leveret, efterhånden som fremskridt fortsætter. Hvis din VPS er påvirket af dette, er du allerede blevet sendt en e-mail med yderligere trin. Hvis der ikke sendes en e-mail til dig - åbn en billet med det samme.

2. 30. juni 2026 kl. 00.52 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 22. september 2025 kl. 22.05 UTCinvestigating

   We've been alerted of an issue with our sofstorage22 node. We've dispatched DC engineers to check the status of the server and attempt recovery.

2. 24. september 2025 kl. 17.35 UTCidentified

   We continue working on the sofstorage22 host node. Unfortunately, at the moment we're unable to restore the RAID array. We're continuing with data recovery and further updates will be posted within 24 hours.

3. 29. januar 2026 kl. 20.02 UTCresolved

   This incident has been resolved.

1. 4. september 2025 kl. 05.13 UTCinvestigating

   We've been alerted of a problem with our nuestorage03 KVM storage Node. Upon checking, we've discovered the node is completely unreachable by IPMI. We've dispatched on-site techs to check the condition of the node. Further updates to follow.

2. 4. september 2025 kl. 05.26 UTCresolved

   This incident has been resolved.

1. 3. september 2025 kl. 05.09 UTCidentified

   We've been alerted by our system that our nueryzenkvm01 host node is currently down. As we're unable to open an IPMI connection, we have engaged Datacenter technicians on-site. Updates to follow.

2. 3. september 2025 kl. 05.27 UTCidentified

   We're currently experiencing a hardware failure and we'll be replacing some parts of the chassis with on-site spares. ETA of resolution: 2-3 hours.

3. 3. september 2025 kl. 07.33 UTCresolved

   This incident has been resolved.

1. 5. juli 2025 kl. 08.58 UTCidentified

   On July 4th, 2025, we detected a catastrophic RAID10 SSD array failure on node nueovz04. Fortunately, this node was in the process of being decommissioned and actively migrated to new infrastructure, so the impact is limited to a small number of customers. Since discovery, we have attempted multiple recovery approaches, including replacing RAID controllers and utilizing advanced data recovery techniques. We are currently preparing an identical server chassis to import the array and attempt further recovery efforts. At this time, we cannot guarantee recovery success or provide a precise ETA, but we are targeting the first half of the upcoming week for the next update or resolution. We sincerely apologize for the inconvenience and thank you for your patience while we work through this. — The AlphaVPS Team

2. 9. juli 2025 kl. 08.33 UTCresolved

   Status: Recovery Unsuccessful – Services Being Recreated Following extensive recovery efforts on node nueovz04, we regret to inform you that we have not been able to restore the RAID10 SSD array. Our team has attempted: - Replacing the RAID controller cache - Replacing the entire RAID controller with multiple known working controllers - Transplanting the drives into an identically configured chassis, with fully matching firmware and hardware Despite all recovery attempts, the RAID array remains inaccessible. At this stage, we must consider the data on this node to be lost. We are now moving forward with recreating affected services on a new node. Our team will be reaching out individually to each impacted customer to coordinate this process. If you were hosted on nueovz04 and have not received an email from us, we urge you to contact our support team as soon as possible. We deeply regret this outcome and sincerely apologize for the disruption. Thank you for your patience and understanding during this time. — The AlphaVPS Team

1. 25. juni 2025 kl. 16.40 UTCidentified

   We've detected an issue with our sofovz06 node. We're working on resolving it. Please stand by for updates.

2. 26. juni 2025 kl. 07.44 UTCresolved

   We've resolved the issue as of 14 hours ago. We've monitored the situation throughout the time and believe that system is now stable.

1. 31. maj 2025 kl. 03.59 UTCidentified

   We've been informed of an urgent DataCenter maintenance in our NYC facility, affecting some of our services there. ETA of service restoration is 1-2 hours.

2. 31. maj 2025 kl. 12.59 UTCresolved

   The incident is fully resolved.

1. 20. december 2024 kl. 07.49 UTCinvestigating

   We've been alerted of a catastrophic RAID failure on our nuestorage07 node. Earlier this morning, the controller started flapping, which jumped the I/O load to over 90. This made every VM on the host hypervisor unresponsive. We've proceeded with replacing the RAID adapter and we're moving towards an attempted recovery. At this point, we're unsure if recovery would be possible.

2. 20. december 2024 kl. 09.31 UTCidentified

   We're currently working on bringing the node back online in a stable state. We estimate that it would take us 3-4 additional hours before we start booting the virtual machines up and assessing the damage. Please stand by for further updates.

3. 20. december 2024 kl. 13.54 UTCidentified

   We are starting with restoration of individual KVM machines. Further updates to follow.

4. 20. december 2024 kl. 21.04 UTCidentified

   We're continuing to work on restoring VMs, if your VM is affected - please wait until it's booted up.

5. 21. december 2024 kl. 14.01 UTCmonitoring

   We'll be booting up the remaining virtual servers in the next 1 hour and continue with monitoring the hypervisor.

6. 21. december 2024 kl. 15.44 UTCmonitoring

   Unfortunately, as we booted up the majority of the affected VMs, the node started becoming unstable again with flush operations starting to get queued. We're looking into alternative solutions at the moment. Further updates to come.

7. 21. december 2024 kl. 23.35 UTCmonitoring

   We've proceeded with replacing additional hardware. After we've performed manual fsck on each virtual machine's virtual drive - we've proceeded with booting up all affected VPS. As of now, all services are restored. We'll be monitoring the situation throughout the next days.

8. 1. januar 2025 kl. 12.08 UTCresolved

   We've monitored the situation for the past 11 days and as of now, everything is stable and we're closing the issue.

1. 27. september 2024 kl. 12.04 UTCidentified

   We've identified an issue with our Nuremberg network. We're working on resolving it.

2. 27. september 2024 kl. 12.10 UTCmonitoring

   A fix has been implemented. The issue was related to a reboot of a virtual chassis member, causing multiple BGP sessions to start flapping. We're monitoring the environment and we'll apply further fixes as necesary.

3. 28. september 2024 kl. 15.38 UTCresolved

   We've been monitoring the situation and a fix has been implemented for this specific edge case. We're closing this as resolved.

1. 9. september 2024 kl. 16.47 UTCinvestigating

   Our monitoring has alerted us that our laxryzenkvm07 node is currently offline. During our investigation, we've found out that we're unable to reach IPMI/BMC as well. We're dispatching on-site technicians to check the status of the server. Further updates to follow!

2. 9. september 2024 kl. 17.15 UTCresolved

   Services are back online now.

1. 18. maj 2024 kl. 10.00 UTCidentified

   Our engineers have identified an upstream-related problem, causing packet loss from certain routes towards our London infrastructure. The issue was identified to be upstream-caused. We're awaiting our London connectivity partners to further update us with an estimation of time for service restoration.

2. 18. maj 2024 kl. 10.10 UTCmonitoring

   The issue seems to be currently resolved but we're awaiting updates from our upstream. We will keep monitoring throughout the day.

3. 18. maj 2024 kl. 13.40 UTCmonitoring

   Our London connectivity partners state that the issue has been identified and resolved. We will continue to monitor the network throughout the day.

4. 18. maj 2024 kl. 17.44 UTCresolved

   As per now - we consider this to be resolved.

1. 12. december 2023 kl. 09.12 UTCidentified

   We've identified a hardware issue with our nueovz04 node and we've immediately taken it offline, pending remote hands in DC to swap some hardware components.

2. 12. december 2023 kl. 10.06 UTCmonitoring

   The node is back online and we'll be monitoring it for stability and further issues.

3. 3. april 2024 kl. 08.57 UTCresolved

   This incident has been resolved.

1. 10. november 2023 kl. 06.09 UTCidentified

   Hello, We've identified an issue in our Sofia location, affecting our network. We've isolated it to our QFX Virtual Chassis Core. We've restored back connectivity on a single member of our Virtual Chassis and no redundancy is present at the moment. We're working on bringing the rest of our VC members online to restore redundancy.

2. 10. november 2023 kl. 09.04 UTCidentified

   We've identified the main problem, which was related to one of the members of our Juniper QFX Virtual Chassis. At the moment, we believe that one of the virtual chassis members suffered a catastrophic failure of internal storage. Unfortunately, this specific Juniper QFX device was the active master in our VC configuration. As per best practices, we run multiple devices, which can take over the mastership when the current master fails, however in this case - this has not happened, as JunOS was partially running on the failing device. The master killed the internal routing sessions and no packets were being transmitted via the secondary devices. Once we determined the root cause, we've done a manual switchover to another VC member and connectivity was restored. We're working on replacing the failing device and bringing it back in our VC to restore redundancy. Service redundancy should still be considered to be at risk. IPv6 connectivity is not restored on 100% yet, as our priority is bringing v4 redundancy back in place. Further updates to follow.

3. 10. november 2023 kl. 09.39 UTCidentified

   As of now, IPv6 connectivity is also restored. We're proceeding with replacing the virtual chassis member.

4. 10. november 2023 kl. 12.34 UTCmonitoring

   We've installed a new QFX member, after initial configuration and restored full redundancy. As of now, all systems are back to being fully redundant again. We'll continue monitoring the infrastructure and close this issue later today.

5. 10. november 2023 kl. 18.19 UTCresolved

   We're closing this incident as resolved.

1. 22. maj 2023 kl. 07.58 UTCidentified

   As per our previous email - we're beginning the pre-scheduled migration of nuestorage* nodes.

2. 22. maj 2023 kl. 08.08 UTCidentified

   We're taking down nuestorage01 node down.

3. 22. maj 2023 kl. 08.23 UTCidentified

   Nuestorage01 is ready and booting up, nuestorage02 is currently being shutdown.

4. 22. maj 2023 kl. 08.47 UTCidentified

   We've shutdown nuestorage03. As of the moment - nuestorage02 shows further hardware problems and we'll shut it down again to further debug.

5. 22. maj 2023 kl. 09.05 UTCidentified

   We've completed the maintenance on nuestorage03 and we've taken back nuestorage02 for further checks. As of now - both nuestorage01 and nuestorage03 can be considered stable.

6. 22. maj 2023 kl. 09.23 UTCresolved

   nuestorage02 node is back up and running. As of now - all nodes are back online and all instability issues should be permanently resolved! We're closing this as resolved.

1. 15. maj 2023 kl. 08.38 UTCinvestigating

   Our monitoring has detected network connectivity issues and packetloss in our LAX location. This seems to be related to our upstream and is out of our scope. We're currently awaiting their network engineers to sort out the problem.

2. 15. maj 2023 kl. 11.22 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 15. maj 2023 kl. 12.42 UTCresolved

   The incident has been resolved and the main cause was a significant peering disturbance in the LA ANY2 peering platform.

1. 25. januar 2023 kl. 12.47 UTCinvestigating

   We've started the pre-scheduled network maintenance in Sofia. Minor and short service disruptions might occur.

2. 25. januar 2023 kl. 15.54 UTCresolved

   We've completed the maintenance without any disruption to client services and are closing the maintenance window.

1. 2. januar 2023 kl. 15.03 UTCinvestigating

   We're investigating a complete network outage in London, related to our upstream. Further news to follow.

2. 2. januar 2023 kl. 16.16 UTCidentified

   As of now, we've restored connectivity to the majority of our clients in London. A small portion of clients residing on a specific network segment are still affected. We're dealing with a large-scale network attack and working closely with our upstreams on completely mitigating the attack.

3. 2. januar 2023 kl. 17.00 UTCresolved

   Our upstream applied some additional mitigation rules on the Corero device and as of now - all clients are back online.