Ιστορικό διακοπών του Teraswitch

1. 12 Αυγούστου 2026 στις 5:18 π.μ. UTCmonitoring

   (Αυτή η κατάσταση διαχωρίζεται από ένα προηγούμενο θέμα που αρχικά πιστευόταν ότι είχε σχέση.) Οι πελάτες σε LON1, AMS1, AMS2, AMS3, DUB1, DUB2, FRA2, SGP1, SGP2, TYO1, TYO2 και TYO3 παρουσίασαν απώλεια προσβασιμότητας σε προορισμούς στο Διαδίκτυο, καθώς και σε εσωτερικούς προορισμούς ραχοκοκαλιάς Teraswitch μεταξύ των επηρεαζόμενων τόπων. Άλλες τοποθεσίες της Βόρειας Αμερικής δεν επηρεάστηκαν. Το MIA1 (Miami, FL) αφαιρέθηκε σκόπιμα από τη ραχοκοκαλιά ως μέρος της απάντησής μας. Το MIA1 παραμένει προσβάσιμο και σε λειτουργία, αλλά λειτουργεί επί του παρόντος χωρίς πλήρη συνδεσιμότητα ραχοκοκαλιάς, η κυκλοφορία προς και από άλλες τοποθεσίες Teraswitch δρομολογείται μέσω του δημόσιου Διαδικτύου και όχι μέσω της ιδιωτικής μας ραχοκοκαλιάς. Οι πελάτες που βασίζονται στο MIA1 για ιδιωτική ραχοκοκαλιά ή συνδεσιμότητα μεταξύ των εγκαταστάσεων θα πρέπει να αναμένουν αλλαγή λανθάνουσας λειτουργίας και χαρακτηριστικά διαδρομής μέχρι την επανολοκλήρωση του MIA1. Αιτία: Ο Teraswitch χρησιμοποιεί μια προκαθορισμένη διαδρομή (0.0.0.0/0) εσωτερικά για να σηματοδοτήσει ότι ένας δρομολογητής άκρων είναι σε θέση να προωθήσει την κυκλοφορία στο Διαδίκτυο. Κάθε τοποθεσία προτιμά κανονικά την προεπιλογή που προέρχεται από τους δικούς του τοπικούς δρομολογητές άκρων, με χαρακτηριστικά διαδρομής να ξεχωρίζουν μια τοπική προέλευση από μια απομακρυσμένη. Μια προεπιλεγμένη διαδρομή που προήλθε από το MIA1 διαδόθηκε με τις μετρικές και τις κοινότητές του να απογυμνώνονται και ένα AS-path που περιέχει μόνο το δικό μας ASN. Αυτή τη στιγμή, κατανοούμε ότι αυτή η διαδρομή δεν υπήρχε ποτέ μέσα στους δρομολογητές της MIA1 ως έγκυρη διαδρομή. Ένας ανακλαστήρας διαδρομής στο site μας AMS2 διεύρυνε αυτή την αλλαγμένη διαδρομή προς τις αγορές της ΕΕ και της APAC. Η λήψη routers άκρο ερμήνευσε ως τοπικά προέρχεται και προτίμησε από τη δική τους έγκυρη τοπική προεπιλογή. Στη συνέχεια, οι δρομολογητές διαφημίζουν τη διαδρομή προς τον πυρήνα του κατάντη κέντρου δεδομένων, ο οποίος την απέρριψε ως άκυρη. Χωρίς να υπάρχει αποδεκτή προεπιλογή, τα προσβεβλημένα υφάσματα της τοποθεσίας σταμάτησαν να προωθούν την κυκλοφορία στα δικά τους routers άκρων, με αποτέλεσμα να παρατηρηθεί απώλεια της προσιτότητας. Ανάλυση: Οι μηχανικοί εντόπισαν τη λανθασμένη διαδρομή μέσα σε 10 λεπτά από την έναρξη και αφαίρεσαν το MIA1 από τη ραχοκοκαλιά για να σταματήσουν περαιτέρω διάδοση. Οι επηρεαζόμενες τοποθεσίες επανακλήθηκαν στις τοπικές προεπιλεγμένες διαδρομές και υπηρεσίες τους αποκαταστάθηκαν στις 04:16:15 UTC. Επόμενα βήματα: Το υποκείμενο ελάττωμα, είτε στους δρομολογητές άκρων MIA1 είτε στον ανακλαστήρα πορείας, δεν έχει ακόμη εντοπιστεί. Δουλεύουμε για να αναπαράγουμε την κατάσταση και έχουμε προσλάβει τον προμηθευτή μας. Στο ενδιάμεσο εφαρμόζουμε πολιτική για την επιβολή ελάχιστων απαιτούμενων χαρακτηριστικών σε εσωτερικές προκαθορισμένες διαδρομές, έτσι ώστε μια λανθασμένη διαφήμιση να μην μπορεί να προτιμηθεί από μια έγκυρη τοπική. Η MIA1 θα παραμείνει εκτός της ραχοκοκαλιάς μέχρι να γίνει κατανοητό το ελάττωμα και να επαληθευθούν οι μετριασμοί· θα δημοσιεύσουμε μια ενημέρωση όταν επανασυνταχθεί. Θα ακολουθήσει πλήρης RFO.

2. 12 Αυγούστου 2026 στις 6:29 μ.μ. UTCresolved

   Working with our network hardware vendor, we have deployed a global change across all compute sites to improve the reliability of the connection between our Internet/backbone edge routers and our data center core networks. This change addresses the blackhole condition that caused the overnight outage. With it in place, a malformed route entering the fabric will no longer prevent traffic forwarding - sites will continue to forward via their local edge routers rather than losing reachability. We considered the previous behavior a critical flaw and have prioritized this fix accordingly. All sites, including the unaffected data centers, had this configuration change completed successfully earlier today. We continue to investigate the underlying condition that caused the default route from MIA1 to be advertised/readvertised with incorrect attributes, and will publish a full RFO once that analysis is complete. Please note: a separate, unrelated incident affecting our global traffic routing systems remains open. That work involves a distinct vendor defect and route scaling improvements, and is not connected to the outage described here.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 29 Ιουλίου 2026 στις 7:15 μ.μ. UTCinvestigating

   Ο Teraswitch ερευνά τη γενική αστάθεια του Διαδικτύου.

2. 29 Ιουλίου 2026 στις 7:35 μ.μ. UTCidentified

   Η Teraswitch εργάζεται επί του παρόντος πάνω σε μετριασμούς που σχετίζονται με αυτό το ζήτημα, αν και τα κυκλοφοριακά ζητήματα έχουν διευθετηθεί. Αυτή τη στιγμή, φαίνεται ότι το μεγαλύτερο μέρος της μεγάλης χωρητικότητας των αμερικανικών καλωδίων προς την ΕΕ είχε ένα σφάλμα περίπου την ίδια περίοδο. Το μονοπάτι της Νέας Υόρκης προς το Λονδίνο, το οποίο είχε κοπεί και επιλυθεί νωρίτερα σήμερα, έπεσε και πάλι κάτω, και το Ashburn μας προς το μονοπάτι της Φρανκφούρτης υπέστη μια διακοπή περίπου την ίδια περίοδο. Αυτή τη στιγμή, το δίκτυο έχει σταθεροποιηθεί και εργαζόμαστε για να διασφαλίσουμε ότι τυχόν πρόσθετα γεγονότα δεν θα έχουν τόσο αντίκτυπο στην κυκλοφορία.

3. 31 Ιουλίου 2026 στις 2:33 μ.μ. UTCmonitoring

   Από τον αρχικό αντίκτυπο, η ομάδα Μηχανικών Δικτύων της Teraswitch έχει εντοπίσει την αστάθεια ως αποτυχία του λογισμικού δρομολόγησης που πυροδοτήθηκε κατά τη διάρκεια μιας αλλαγής διαμόρφωσης ρουτίνας. Αφαιρέσαμε την κατάσταση ενεργοποίησης και εφαρμόσαμε διασφαλίσεις για την πρόληψη της επανάληψης. Το δίκτυο παραμένει σταθερό ενώ ολοκληρώνουμε αναβαθμίσεις λογισμικού και μόνιμη αποκατάσταση. Το τρέχον χρονοδιάγραμμα των γεγονότων είναι ότι η αστάθεια πυροδοτήθηκε περίπου στις 19:09:21–27 UTC στις 29 Ιουλίου 2026, και διήρκεσε για ~5 λεπτά. Περισσότερες ενημερώσεις και μια ολοκληρωμένη RCA θα κυκλοφορήσει σε μελλοντικές ενημερώσεις.

4. 12 Αυγούστου 2026 στις 4:01 π.μ. UTCinvestigating

   [This message has been deleted, a distinct incident has been opened instead.]

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 28 Ιουλίου 2026 στις 4:17 μ.μ. UTCinvestigating

   Teraswitch εξετάζει θέματα που σχετίζονται με το R102 roxute rack εντός TYO2.

2. 28 Ιουλίου 2026 στις 4:52 μ.μ. UTCresolved

   Εντοπίστηκε ένα πιθανό σφάλμα firmware/hardware, και η Teraswitch NOC επέλεξε να κάνει μια διαδοχική αναβάθμιση λογισμικού στο περιττό ζεύγος switch στο R102. Μετά την ολοκλήρωση των επαναφορτώσεων, οι επιχειρήσεις φαίνονταν να εξομαλυνθούν. Θα ερευνήσουμε αυτό το ζευγάρι για να καταλάβουμε καλύτερα το γεγονός. Παρακαλώ αναφέρετε τυχόν εκκρεμή ζητήματα με το TYO2 στο [email protected] ή στην ομάδα μας άμεσα.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 17 Ιουλίου 2026 στις 11:45 μ.μ. UTCinvestigating

   Η Teraswitch ερευνά αναφορές για απώλεια συνδεσιμότητας στο Διαδίκτυο στο SGP2. Θα σας ενημερώσουμε σύντομα.

2. 18 Ιουλίου 2026 στις 12:22 π.μ. UTCidentified

   Η Teraswitch έχει απομονώσει αυτό το περιστατικό σε ένα γεγονός συντήρησης ισχύος του πωλητή με απροσδόκητη επίπτωση, επηρεάζοντας και τις δύο ράφια του δικτύου μας και προκαλώντας απώλεια συνδεσιμότητας στο Internet στο SGP2. Οι υπηρεσίες πελατών πιστεύεται ότι τροφοδοτούνται χωρίς ανάντη συνδεσιμότητα. Το προσωπικό των εγκαταστάσεων εργάζεται για την αποκατάσταση της συνδεσιμότητας του Διαδικτύου και την επαναφορά του ιστότοπου σε απευθείας σύνδεση. Θα σας ενημερώσουμε το συντομότερο δυνατόν.

3. 18 Ιουλίου 2026 στις 1:57 π.μ. UTCresolved

   Ο συνεργάτης μας αποκατέστησε την ισχύ στα ράφια δικτύου του Τέρασγουιτς. Αιτία ρίζας: και τα δύο περιττά PDU σε κάθε ράφι δικτύου τροφοδοτούνταν από κουτιά διακοπής ρεύματος που συνδέονταν με την ίδια εναέρια γραμμή ηλεκτρικών λεωφορείων, δημιουργώντας ένα μόνο σημείο αποτυχίας. Οι μηχανικοί εγκαταστάσεων μετεγκατάστασαν ένα κιβώτιο διαφυγής στο σωστό λεωφορείο, αποκαθιστώντας την ισχύ στον εξοπλισμό του δικτύου και εξαλείφοντας το μοναδικό σημείο αποτυχίας. Αυτή τη στιγμή δεν αναμένουμε περαιτέρω επιπτώσεις. Τα συστήματα πελατών δεν έχασαν ισχύ σε κανένα σημείο κατά τη διάρκεια αυτού του γεγονότος.

Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.

1. 8 Ιουλίου 2026 στις 5:48 μ.μ. UTCinvestigating

   Teraswitch is investigating reports of intermittent network connectivity issues affecting some services in our EWR2 (Newark, NJ) location.

2. 8 Ιουλίου 2026 στις 6:01 μ.μ. UTCidentified

   We have identified the issue affecting network connectivity in our EWR2 (Newark, NJ) location and are implementing corrective changes.

3. 8 Ιουλίου 2026 στις 6:01 μ.μ. UTCidentified

   We have located an unstable core router in EWR2 and have implemented mitigations to divert traffic away from it.

4. 8 Ιουλίου 2026 στις 6:20 μ.μ. UTCresolved

   Teraswitch monitoring reports that all impacts are currently resolved. Please report any further issues to our team. At EWR2, a device sitting between our data center fabric and our internet edge routers experienced a hardware fault that triggered an ASIC-level reload. After the reload, the device came back online in a degraded state and was unable to forward traffic from the data center fabric to the internet edge routers (specifically, it could not process VXLAN-routed traffic). EWR2 operates six of these core routers. Five were unaffected; however, the impaired unit failed to signal that it was incapable of forwarding traffic. Because downstream routing protocols did not detect this bad state, traffic that landed on the affected device was blackholed. Our team manually removed the router from the pool of forwarding destinations for this traffic, restoring service. We will perform all necessary follow-up steps to fully resolve the underlying issue and prevent recurrence.

1. 10 Ιουνίου 2026 στις 12:24 π.μ. UTCmonitoring

   Teraswitch identified a brief impact to network connectivity at our DUB1 and DUB2 sites beginning at 23:43 UTC. Undersea cables from both London and Amsterdam were lost, resulting in the brief loss of backbone and Internet connectivity at DUB1 and DUB2. Traffic was quickly restored via Internet routes and backbone connectivity via London followed shortly thereafter. Repair of the Amsterdam cable is also underway. Teraswitch is monitoring to confirm stability at these sites and will provide an update in the event of any further issues.

2. 23 Ιουνίου 2026 στις 6:43 μ.μ. UTCresolved

   The Concerto cable was fully restored - multiple redundant links are now back online.

1. 4 Ιουνίου 2026 στις 3:27 μ.μ. UTCidentified

   Teraswitch has identified a loss of two undersea cables landing in our SEA1 location from Tokyo. This is likely a terrestrial issue inside Seattle. Traffic was automatically diverted to our LA to Tokyo path.

2. 4 Ιουνίου 2026 στις 9:11 μ.μ. UTCresolved

   Tokyo to Seattle has been nominal operation for many hours now. We are working with our vendors to understand the issue, but at this time we consider the incident and impact resolved.

1. 12 Μαΐου 2026 στις 9:18 μ.μ. UTCinvestigating

   Teraswitch is investigating an issue affecting customer management of VAN1 services (power controls, virtual console, metadata retrieval, new service creation, reinstalls). VAN1 services themselves are unaffected by this issue and should be fully operational. We will provide an update as more information becomes available.

2. 12 Μαΐου 2026 στις 9:50 μ.μ. UTCmonitoring

   Customer management of VAN1 services should be restored at this time. Teraswitch staff are monitoring for any further impacts.

3. 22 Μαΐου 2026 στις 6:22 μ.μ. UTCresolved

   This incident has been resolved.

1. 7 Μαΐου 2026 στις 2:03 π.μ. UTCinvestigating

   Teraswitch is investigating a core router failure in TYO2. Traffic is routing over the remaining redundant routers.

2. 7 Μαΐου 2026 στις 2:29 π.μ. UTCmonitoring

   After an emergency software upgrade, the router is normalized. Teraswitch is monitoring the operation for further errors.

3. 22 Μαΐου 2026 στις 6:24 μ.μ. UTCresolved

   This incident has been resolved.

1. 30 Απριλίου 2026 στις 11:33 μ.μ. UTCidentified

   Teraswitch has identified a top-of-rack switch failure at our TYO1 site affecting a small subset of customers there. Services single homed to this switch are currently offline. We are working on an immediate replacement and will provide updates as more information becomes available.

2. 1 Μαΐου 2026 στις 4:01 π.μ. UTCidentified

   The failed switch has been replaced and is being finalized for production. We will provide an update once affected services are fully restored.

3. 1 Μαΐου 2026 στις 5:44 π.μ. UTCmonitoring

   Our replacement switch is in service and all affected services should be restored at this time. If you have any further issues, please contact Teraswitch Support at [email protected].

4. 1 Μαΐου 2026 στις 5:30 μ.μ. UTCresolved

   This incident has been resolved.

1. 26 Μαρτίου 2026 στις 10:08 μ.μ. UTCidentified

   Teraswitch is working to resolve a simultaneous backbone fiber cut affecting AMS1 connectivity.

2. 26 Μαρτίου 2026 στις 10:53 μ.μ. UTCidentified

   We are working on a resolution to a multiple diverse fiber cut that is impacting AMS1 connectivity. The issue has been identified by the fiber vendor, and we are working on an alternative fiber solution to restore connectivity.

3. 27 Μαρτίου 2026 στις 12:14 π.μ. UTCmonitoring

   We have implemented a temporary fix and AMS1 connectivity is now restored. We will follow up with a permanent fix and RCA.

4. 2 Απριλίου 2026 στις 10:38 μ.μ. UTCresolved

   An RCA has been posted for this issue.

5. 2 Απριλίου 2026 στις 10:38 μ.μ. UTCpostmortem

   # Root Cause Analysis: AMS1 Connectivity Outage **Incident Date:** March 26, 2025 **Duration:** ~1h 21m \(22:08 UTC – 00:14 UTC \+1\) **Severity:** Critical – Full site connectivity loss **Affected Site:** AMS1 – Amsterdam, Netherlands **Status:** Resolved ## Executive Summary On March 26, 2025, Teraswitch's AMS1 facility experienced a complete loss of backbone connectivity lasting approximately 1 hour and 21 minutes. The outage was caused by a scheduled fiber vendor maintenance window that simultaneously impacted both the primary and what was believed to be a diverse redundant fiber path between AMS1 and the rest of the backbone. Investigation revealed that due to a documentation and handoff error at the fiber vendor dating back over a year, the AMS1–AMS2 fiber span had never been migrated to the intended diverse path as part of the AMS3 ring buildout. As a result, both affected spans shared physical infrastructure, eliminating the redundancy intended to protect against exactly this type of event. Connectivity was restored within the maintenance window after a rapid joint audit with the fiber vendor confirmed the provisioning discrepancy, and the AMS1–AMS2 span was moved to its correct diverse path. ## Background Teraswitch's Amsterdam backbone originally consisted of a single dark fiber span between AMS1 and AMS2. When AMS3 was later brought online, the network design called for a three-node fiber ring with fully diverse physical paths between all sites to provide redundant backbone connectivity. To support this design, the fiber vendor was engaged to: 1. Provision a new AMS1–AMS3 span 2. Provision a new AMS2–AMS3 span 3. Reroute the existing AMS1–AMS2 span onto a physically diverse path Due to an internal handoff and documentation error within the fiber vendor, step 3 was not completed. The AMS1–AMS2 span remained on its original physical route. Teraswitch was not made aware of this omission, and the span continued to operate normally for over a year. Because it carried live traffic and appeared correctly in topology, it was not identified as incorrectly provisioned during subsequent audits. ## Timeline of Events | Time \(UTC\) | Event | | --- | --- | | Prior to March 26 | Fiber vendor schedules routine maintenance affecting Amsterdam infrastructure | | ~22:08 | AMS1 backbone connectivity lost. Both AMS1–AMS2 and AMS1–AMS3 paths go down simultaneously. Teraswitch NOC begins triage. | | ~22:53 | Fiber vendor engaged and confirms maintenance is impacting both spans. Root cause identified as shared physical infrastructure due to the original provisioning error. | | ~00:14 \+1 | Fiber vendor migrates AMS1–AMS2 span to the correct diverse physical path. Connectivity restored. Monitoring confirmed stable. | ## Root Cause **Primary cause:** An internal documentation and handoff failure at the fiber vendor resulted in the AMS1–AMS2 dark fiber span never being migrated to its intended physically diverse route during the AMS3 ring buildout. Both the AMS1–AMS2 and AMS1–AMS3 spans shared common physical infrastructure, making the designed ring topology's redundancy ineffective. **Contributing factor:** Because the span was operationally active and traffic was flowing normally, the provisioning error went undetected across both Teraswitch and vendor records for over a year. When the scheduled maintenance affected the shared physical infrastructure, both paths were impacted simultaneously, leaving AMS1 with no available backbone connectivity. ## Impact * **AMS1 customers** experienced a complete loss of inbound and outbound connectivity for approximately 1 hour and 21 minutes. * No data loss or hardware damage occurred. * All other Teraswitch sites were unaffected. ## Resolution Working jointly with the fiber vendor during the incident, Teraswitch engineers and vendor technicians audited the physical path assignments for all Amsterdam spans. The discrepancy between the intended and actual routing of the AMS1–AMS2 span was identified. The vendor migrated the span to the correct physically diverse path, restoring independent redundant connectivity across the AMS1–AMS2–AMS3 ring as originally designed. ## Corrective Actions | Action | Owner | Status | | --- | --- | --- | | Confirm and document physical path diversity for all three Amsterdam spans with fiber vendor | Teraswitch / Fiber Vendor | Complete | | Obtain updated as-built fiber records from vendor reflecting correct path assignments | Fiber Vendor | Complete | | Audit all other Teraswitch sites for similar provisioning discrepancies against vendor records | Teraswitch | Complete | | Establish a fiber path verification checklist for all future vendor provisioning work prior to accepting new spans | Teraswitch | Planned | | Add physical diversity validation to change management process for any future ring or redundancy buildouts | Teraswitch | Planned | | Incorporate optical span latency validation against fiber path build sheets as an acceptance criterion for new span provisioning | Teraswitch | Planned | ## Lessons Learned * **Operational traffic is not proof of correct provisioning.** A span can carry live traffic for an extended period while still being routed incorrectly relative to its intended physical diversity design. * **Redundancy assumptions must be periodically verified against vendor as-built records**, not solely inferred from operational status. * **Fiber vendor handoffs require explicit acceptance criteria** including documented physical path confirmation before provisioning work is considered complete. * **Span latency is a low-cost signal for path verification.** In post-incident review, Teraswitch noted that the measured propagation latency on the AMS1–AMS2 span was slightly lower than expected based on the fiber path build sheet for the intended diverse route. This discrepancy, while subtle, was consistent with the span still traversing the shorter original path. Validating measured latency against estimated values from build sheets at provisioning acceptance could have surfaced this error significantly earlier. This check will be incorporated into the span acceptance process going forward. _RCA prepared by Teraswitch Network Engineering. For questions contact the NOC or network architecture team._

1. 19 Μαρτίου 2026 στις 9:43 μ.μ. UTCmonitoring

   Teraswitch is investigating reports of network connectivity issues affecting some services at our EWR2 site. We have identified the likely cause and implemented a fix, and are monitoring to verify that the issue is resolved.

2. 25 Μαρτίου 2026 στις 10:00 μ.μ. UTCresolved

   This incident has been resolved.

1. 17 Μαρτίου 2026 στις 8:05 μ.μ. UTCinvestigating

   Teraswitch is investigating reports of select markets having issues connecting to PIT1.

2. 17 Μαρτίου 2026 στις 8:36 μ.μ. UTCidentified

   We have located a network device with software issues, our team is about to reload the device. This issue affects mostly colocation customers at PIT1, but traffic from various sources may have passed through this device depending on the direction of network flow.

3. 17 Μαρτίου 2026 στις 8:43 μ.μ. UTCmonitoring

   Reload is complete and the network operation appears to have returned to normal. We will follow up this notification with a RCA and repair plan.

4. 25 Μαρτίου 2026 στις 10:03 μ.μ. UTCresolved

   This incident has been resolved.

1. 20 Φεβρουαρίου 2026 στις 7:47 π.μ. UTCinvestigating

   Teraswitch is investigating a loss of the majority of VAN1 internet connectivity - possibly related to issues in Seattle.

2. 20 Φεβρουαρίου 2026 στις 11:32 π.μ. UTCresolved

   Cogent has recovered as of 4:33am Eastern. Services should be normalized at this time.

1. 20 Φεβρουαρίου 2026 στις 7:01 π.μ. UTCidentified

   TeraSwitch is aware and tracking a loss of two paths from Seattle to Tokyo. This has caused much of the internet traffic to divert via public Internet Transit.

2. 24 Φεβρουαρίου 2026 στις 3:44 μ.μ. UTCresolved

   This incident has been resolved.

1. 19 Φεβρουαρίου 2026 στις 2:08 π.μ. UTCidentified

   We have reached out to the vendor asking for a update. Latency from Singapore to Europe will be elevated until the outage is resolved.

2. 9 Μαρτίου 2026 στις 2:08 π.μ. UTCresolved

   We have successfully brought online a second diverse sub-sea cable path and latency has returned to normal. Once the original severed cable comes back online, we will now have full path redundancy.

1. 4 Φεβρουαρίου 2026 στις 2:26 μ.μ. UTCidentified

   Teraswitch has identified thre core backbone links that are down within the central US. This is causing US-East traffic to wrap around the world to get to US-West. Chicago/Seattle Chicago/Salt Lake City Dallas /Los Angeles We are working with our fiber vendors for a ETR.

2. 4 Φεβρουαρίου 2026 στις 4:04 μ.μ. UTCmonitoring

   Chicago to Salt Lake City path is restored which has normalized operations with 1 of 3 links restored. We will close this status when 2 of 3 are restored which also restores redundancy.

3. 9 Φεβρουαρίου 2026 στις 4:46 μ.μ. UTCresolved

   This incident has been resolved.

1. 3 Φεβρουαρίου 2026 στις 7:54 μ.μ. UTCidentified

   Teraswitch is investigating reports that our console (console.tsw.io) is currently inaccessible. This issue has been identified as the result of an outage in an underlying cloud provider. We will provide an update as more information becomes available.

2. 3 Φεβρουαρίου 2026 στις 9:16 μ.μ. UTCidentified

   This issue is due to an ongoing Cloudflare outage: https://www.cloudflarestatus.com/incidents/m1xvmqf37z97. Cloudflare has implemented a fix and we are monitoring for recovery. Our API is unaffected by this issue and remains accessible.

3. 3 Φεβρουαρίου 2026 στις 10:37 μ.μ. UTCresolved

   Cloudflare has resolved the issue, and console.tsw.io is accessible once again as of 22:28 UTC. This incident has been resolved.

1. 30 Ιανουαρίου 2026 στις 9:53 π.μ. UTCinvestigating

   We are investing significant packet loss on the west coast US.

2. 30 Ιανουαρίου 2026 στις 10:06 π.μ. UTCinvestigating

   We are continuing to investigate this issue.

3. 30 Ιανουαρίου 2026 στις 10:30 π.μ. UTCresolved

   This incident has been resolved.

1. 28 Ιανουαρίου 2026 στις 2:17 μ.μ. UTCresolved

   At 2PM UTC, Teraswitch reloaded software related to our route servers to fix "stuck" transport tunneling sessions. This may have caused interruptions to ULL/HFT and transport services over our network. We believe the first stuck session started approximately 6 hours before, with more dropping off over the next few hours. As of this moment, all stuck sessions appear to be resolved, and traffic is passing normally and via ULL links.