Istoricul incidentelor Alphavps

1. 30 iulie 2026 la 12:50 UTCidentified

   Am început întreținerea hardware preventiv pe următoarele noduri: SOFSTORAGE01 SOFSTORAGE06 SOFSTORAGE07 Cazurile VPS găzduite pe nodurile afectate pot suferi o întrerupere temporară. Timpul de repaus estimat este de aproximativ 15 până la 30 minute per VPS. Echipa noastră monitorizează îndeaproape întreținerea și va oferi actualizări suplimentare pe măsură ce activitatea progresează.

2. 30 iulie 2026 la 13:13 UTCidentified

   Începem să lucrăm la SOFSTORAGE07. VMS-urile au fost închise graţios şi vor fi repornite în scurt timp.

3. 30 iulie 2026 la 13:25 UTCidentified

   Am terminat munca pe SOFSTORAGE07 și mașini virtuale sunt booting înapoi în sus. Mergem mai departe cu SOFSTORAGE01, mașinile virtuale sunt în curs de închidere și de întreținere începe.

4. 30 iulie 2026 la 14:00 UTCidentified

   Am terminat munca pe SOFSTORAGE01 și mașini virtuale sunt booting înapoi în sus. Mergem mai departe cu SOFSTORAGE06, mașinile virtuale sunt în curs de oprire și de întreținere începe.

5. 31 iulie 2026 la 10:55 UTCidentified

   SOSTORAGE06 întreţinerea se face şi toate VMS sunt de pornire în sus.

Traducere automată din actualizarea oficială a incidentului.

1. 29 iunie 2026 la 18:42 UTCidentified

   În prezent experimentăm un atac DDoS la scară largă care vizează porțiuni ale infrastructurii noastre de rețea. Acest atac cauzează probleme intermitente de conectivitate și creșterea latenței pentru unii clienți. Echipa noastră de inginerie a rețelei lucrează activ pentru a implementa măsuri suplimentare de atenuare permanentă pentru a aborda pe deplin acest atac și pentru a consolida în continuare reziliența infrastructurii noastre. Atenuarea temporară este deja în vigoare și continuăm să monitorizăm și să ne adaptăm apărarea pe măsură ce atacul evoluează. Ne cerem sincer scuze pentru orice întrerupere care ar putea cauza și aprecia răbdarea dumneavoastră în timp ce lucrăm pentru o rezoluție completă și permanentă. Vor fi furnizate noi actualizări pe măsură ce se înregistrează progrese.

2. 29 iunie 2026 la 19:39 UTCidentified

   Continuăm să lucrăm la o soluție pentru această problemă.

3. 29 iunie 2026 la 20:01 UTCidentified

   Am aplicat atenuarea în Nürnberg. Sofia este în aşteptare şi ar trebui aplicată în scurt timp. În timp ce avem de-a face cu un atac de extorcare de fonduri, nu putem împărtăşi mai multe detalii public.

4. 29 iunie 2026 la 21:22 UTCidentified

   În timp ce atacatorii maliţioşi schimbă constant tiparele atacului, aplicăm atenuarea şi majoritatea clienţilor noştri sunt online. Suntem angajarea de aplicare a legii locale în situația, de asemenea. Informaţii suplimentare de urmat.

5. 30 iunie 2026 la 00:52 UTCmonitoring

   Am implementat atenuarea tuturor locaţiilor şi traficul a revenit la normal. S-ar putea să existe variaţii în ICMP, dar avem încredere că problema se rezolvă complet.

6. 30 iunie 2026 la 07:30 UTCmonitoring

   Continuăm să monitorizăm situaţia şi să aplicăm ajustări de atenuare. Toate serviciile din toate locațiile sunt online și sunt considerate stabile în prezent.

7. 30 iunie 2026 la 07:36 UTCmonitoring

   Continuăm să monitorizăm orice alte probleme.

8. 30 iunie 2026 la 16:38 UTCmonitoring

   Monitorizăm situaţia şi reglăm profilul de atenuare în toate locaţiile pentru a asigura funcţionarea fără probleme a aparatelor de atenuare cu întreruperi minime.

9. 9 iulie 2026 la 03:44 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 27 mai 2026 la 12:56 UTCidentified

   Am început întreținerea de urgență a rețelei în locația noastră din New York pentru a implementa o nouă conectivitate în amonte după ieșirea neașteptată a actualului furnizor din instalație. Detalii suplimentare sunt trimise prin email tuturor clienților virtuali afectați. În timpul acestei întrețineri, unii clienți ar putea experimenta întreruperi intermitente ale conectivității sau perioade temporare de timp în timp ce se desfășoară activități de migrare a rețelelor. Fereastra de întreținere este de așteptat să dureze până la 8 ore, deși credem că perturbarea reală va fi semnificativ mai scurtă. Ne cerem sincer scuze pentru scurt timp și orice neplăceri cauzate. Acest upgrade este un pas important spre îmbunătățirea stabilității pe termen lung și a calității serviciilor noastre din New York. Alte actualizări vor fi postate aici pe măsură ce progresul continuă.

2. 27 mai 2026 la 15:28 UTCmonitoring

   Am terminat cu actualizarea rețelei și de la 1 oră - toată rețeaua este stabilă. Vom continua monitorizarea pentru câteva ore, până când vom închide cazul.

3. 30 iunie 2026 la 00:51 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 7 aprilie 2026 la 09:31 UTCidentified

   A avut loc o defecţiune critică la depozitul Dal01. Controlerul RAID a intrat într-o stare instabilă și a continuat operațiunile de scriere, ceea ce a dus la corupția mai multor imagini de disc KVM. Nodul a fost deconectat imediat pentru a preveni impactul ulterior. Controlorul RAID a fost înlocuit și procedurile de recuperare sunt în curs de desfășurare. Datorită dimensiunii array-ului, recuperarea este o perioadă mare de timp și coerența datelor nu poate fi garantată. În acest moment, capacitatea disponibilă în Dallas este limitată. Lucrăm activ la implementarea hardware-ului suplimentar, însă nu s-a confirmat încă un ETA exact. Clienţii afectaţi beneficiază de servicii de înlocuire în locaţii alternative. Accesul la salvare poate fi activat la cerere pentru recuperarea datelor cel mai eficient. Alte actualizări vor fi furnizate pe măsură ce progresul continuă. Dacă VPS este afectat de acest lucru, ați fost deja trimis un e-mail cu pași suplimentari. Dacă nu vă este trimis niciun e-mail - vă rugăm să deschideţi imediat un bilet.

2. 30 iunie 2026 la 00:52 UTCresolved

   Acest incident a fost rezolvat.

Traducere automată din actualizarea oficială a incidentului.

1. 22 septembrie 2025 la 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 septembrie 2025 la 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 ianuarie 2026 la 20:02 UTCresolved

   This incident has been resolved.

1. 4 septembrie 2025 la 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 septembrie 2025 la 05:26 UTCresolved

   This incident has been resolved.

1. 3 septembrie 2025 la 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 septembrie 2025 la 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 septembrie 2025 la 07:33 UTCresolved

   This incident has been resolved.

1. 5 iulie 2025 la 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 iulie 2025 la 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 iunie 2025 la 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 iunie 2025 la 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 mai 2025 la 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 mai 2025 la 12:59 UTCresolved

   The incident is fully resolved.

1. 20 decembrie 2024 la 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 decembrie 2024 la 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 decembrie 2024 la 13:54 UTCidentified

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

4. 20 decembrie 2024 la 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 decembrie 2024 la 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 decembrie 2024 la 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 decembrie 2024 la 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 ianuarie 2025 la 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 septembrie 2024 la 12:04 UTCidentified

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

2. 27 septembrie 2024 la 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 septembrie 2024 la 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 septembrie 2024 la 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 septembrie 2024 la 17:15 UTCresolved

   Services are back online now.

1. 18 mai 2024 la 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 mai 2024 la 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 mai 2024 la 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 mai 2024 la 17:44 UTCresolved

   As per now - we consider this to be resolved.

1. 12 decembrie 2023 la 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 decembrie 2023 la 10:06 UTCmonitoring

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

3. 3 aprilie 2024 la 08:57 UTCresolved

   This incident has been resolved.

1. 10 noiembrie 2023 la 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 noiembrie 2023 la 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 noiembrie 2023 la 09:39 UTCidentified

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

4. 10 noiembrie 2023 la 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 noiembrie 2023 la 18:19 UTCresolved

   We're closing this incident as resolved.

1. 22 mai 2023 la 07:58 UTCidentified

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

2. 22 mai 2023 la 08:08 UTCidentified

   We're taking down nuestorage01 node down.

3. 22 mai 2023 la 08:23 UTCidentified

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

4. 22 mai 2023 la 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 mai 2023 la 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 mai 2023 la 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 mai 2023 la 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 mai 2023 la 11:22 UTCmonitoring

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

3. 15 mai 2023 la 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 ianuarie 2023 la 12:47 UTCinvestigating

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

2. 25 ianuarie 2023 la 15:54 UTCresolved

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

1. 2 ianuarie 2023 la 15:03 UTCinvestigating

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

2. 2 ianuarie 2023 la 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 ianuarie 2023 la 17:00 UTCresolved

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