Το Prod2 ήταν διαλείπτως μη διαθέσιμο
- investigating
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
- resolved
Το περιστατικό λύθηκε.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
88 Harness incidents · Μάρτιος 2026 — official updates, affected components, duration and resolution details.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Το περιστατικό λύθηκε.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Η εκτέλεση του αγωγού κόλλησε στο Prod1. Ερευνούμε το θέμα.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Το θέμα έχει εντοπιστεί και υλοποιείται μια λύση.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
Περίληψη Μεταξύ 27 Αυγούστου και 28 Αυγούστου 2026, οι πελάτες αντιμετώπισαν ένα θέμα όπου εμφανίστηκαν ορισμένοι αγωγοί, εγκαταστάσεις και συναφείς πόροι, όπως δεν βρέθηκαν στο Harness UI και API, παρόλο που τα υποκείμενα δεδομένα παρέμειναν άθικτα. Το ζήτημα προέκυψε κατά τη διάρκεια μιας προγραμματισμένης επικαιροποίησης της εσωτερικής υποδομής που επηρέασε την επικοινωνία μεταξύ των υπηρεσιών εσωτερικής πλατφόρμας. Ως αποτέλεσμα, τα αιτήματα που εξαρτιόνταν από το λογαριασμό, την οργάνωση και την επίλυση του πεδίου εφαρμογής του έργου δεν ήταν σε θέση να ολοκληρώσουν επιτυχώς, γεγονός που οδήγησε σε λανθασμένη μη διαπίστωση ότι οι απαντήσεις επιστρέφονται σε πελάτες για υφιστάμενες οντότητες. Το μηχανοστάσιο αναγνώρισε το θέμα, γύρισε πίσω την αλλαγή, και αποκατέστησε την κανονική υπηρεσία. Δεν χάθηκαν ή διαγράφηκαν δεδομένα πελατών κατά τη διάρκεια του συμβάντος. Αιτία ρίζας Το θέμα προκλήθηκε από σφάλμα ρύθμισης που εισήχθη κατά τη διάρκεια προγραμματισμένης ενημέρωσης δρομολόγησης εσωτερικής υπηρεσίας στην Παραγωγή. Μια εσωτερική υπηρεσία πλατφόρμας που είναι υπεύθυνη για την επίλυση του λογαριασμού, της οργάνωσης και του πλαισίου του έργου δεν μπόρεσε να επικυρώσει αιτήματα από άλλες υπηρεσίες Harness μετά την εφαρμογή της αλλαγής. Επειδή αυτό το βήμα επικύρωσης απαιτείται πριν από πολλές ενδείξεις της οντότητας και ενέργειες που σχετίζονται με αγωγούς μπορούν να προχωρήσουν, τα αποτυχημένα αιτήματα εμφανίστηκαν στους πελάτες καθώς δεν βρέθηκαν σφάλματα για πόρους που συνέχισαν να υπάρχουν κανονικά. Το θέμα περιορίστηκε στο περιβάλλον παραγωγής που επηρεάστηκε και επιλύθηκε επαναφέροντας την αλλαγή και επαναφέροντας την προηγούμενη πορεία επικοινωνίας υπηρεσιών. Σύγκρουση * Μερικοί πελάτες είδαν υπάρχοντες αγωγούς, ανάπτυξη, και συναφείς οντότητες εμφανίζονται ως δεν βρέθηκαν στο UI και API. * Μερικές λειτουργίες που σχετίζονται με αγωγούς, συμπεριλαμβανομένης της εξέλιξης της εκτέλεσης, webhook- ενεργοποιηθεί ξεκινά, προγραμματισμένη αξιολόγηση σκανδάλης, και λίστα οντοτήτων, προσωρινά διαταράχθηκαν. * Το θέμα επηρέασε τη διαθεσιμότητα και την προβολή των υπαρχουσών οντοτήτων, αλλά δεν αφαίρεσε τα δεδομένα ούτε άλλαξε τις διαμορφώσεις των πελατών. * Δεν εμφανίστηκε μη εξουσιοδοτημένη πρόσβαση, και δεν παρατηρήθηκε απώλεια δεδομένων πελατών. . . . Αποκατάσταση * * * * Άμεση: ** Επανέστρεψε την επικαιροποίηση της διαμόρφωσης της υποδομής και αποκατέστησε την ήδη λειτουργική διαδρομή επικοινωνίας υπηρεσιών. * * **Επικύρωση ανάκτησης: ** Επαληθεύτηκε ότι οι θιγόμενες αναζητήσεις οντοτήτων, οι λειτουργίες αγωγών και τα εξαρτώμενα API λειτουργούσαν κανονικά μετά την αναστροφή. * * * * Μόνιμη ** Διορθώθηκε ο χειρισμός ρυθμίσεων που σχετίζεται με την ενημέρωση, ώστε παρόμοια ζητήματα να μην παρεμβαίνουν στην ταυτοποίηση από υπηρεσία σε υπηρεσία στο μέλλον. . . . Στοιχεία δράσης Για να αποτρέψουν τέτοια ζητήματα από το να συμβούν ξανά, ο Harness θα 1. Βελτίωση της επικύρωσης της διαμόρφωσης με την ενίσχυση των δοκιμών πριν από την ανάπτυξη για την επαλήθευση της εσωτερικής επικοινωνίας υπηρεσιών πριν από τη μετατόπιση της κυκλοφορίας παραγωγής. 2. Ενισχύστε την παρακολούθηση και την ειδοποίηση για εσωτερικές αποτυχίες ταυτοποίησης, έτσι ώστε τα ζητήματα μπορούν να ανιχνευθούν νωρίτερα. 3. Βελτίωση του χειρισμού σφαλμάτων έτσι ώστε οι αποτυχίες εξάρτησης είναι λιγότερο πιθανό να εμφανιστούν στους πελάτες ως πόρος που δεν βρέθηκαν σφάλματα.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή διερευνούμε ένα θέμα που αναφέρεται στους αγωγούς IACM σε συστάδες αγωγών Prod-1 , Prod-2 , Prod-4 και EU1.
Συνεχίζουμε να ερευνούμε αυτό το ζήτημα.
Επιστρέψαμε την αλλαγή που προκάλεσε αυτό το ζήτημα σε όλες τις ομάδες.
Το περιστατικό λύθηκε.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Αυτή τη στιγμή ερευνούμε αναφορές ότι η διεπαφή χρήστη Διαχείρισης & Πειραματισμού Χαρακτηριστικών (FME) αποτυγχάνει να φορτώσει. Οι πελάτες που προσπαθούν να έχουν πρόσβαση στην κονσόλα FME μπορεί να αντιμετωπίσουν λάθη ή σελίδες που δεν ανταποκρίνονται. Αξιολόγηση της σήμανσης και η κυκλοφορία SDK δεν πιστεύεται ότι επηρεάζονται. Μια περαιτέρω ενημέρωση θα ακολουθήσει σύντομα.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
Περίληψη * Ξεκινώντας από **23:42 UTC** στις 23 Αυγούστου 2026, αρκετοί πελάτες FME ανέφεραν αποτυχίες φόρτωσης του FME UI. * FME UI Artifacts που εξυπηρετούνται από το CDN έληξε λόγω μιας πολιτικής διατήρησης, προκαλώντας FME UI να αποτύχει να φορτώσει. * Κάθε αίτημα σημαίας αλλάζει μέσω του API, αλλαγή παράδοσης, και ο αγωγός δεδομένων συνέχισε να λειτουργεί χωρίς διακοπή. Αιτία ρίζας * Το FME UI σερβίρεται από ένα CDN. Τα τεχνουργήματα του UI εκδιώχθηκαν λόγω μιας πολιτικής διατήρησης, προκαλώντας την αποτυχία του UI να φορτώσει για όλους τους χρήστες. Σύγκρουση * Το FME UI δεν μπόρεσε να φορτώσει για όλους τους χρήστες σε όλα τα περιβάλλοντα παραγωγής. Τι δεν επηρεάστηκε; * SDK λειτουργικότητα και αξιολόγηση runtime σημαία * Admin API κλήσεις * Δεδομένα διαμόρφωσης της σημαίας πελατών * Δεν παρουσιάστηκε απώλεια δεδομένων . . . Αποκατάσταση * FME UI αποκαταστάθηκε στο CDN μέσω μιας ανάπτυξης * Η ανάκτηση επιβεβαιώθηκε σε όλα τα περιβάλλοντα παραγωγής πριν από το κλείσιμο του συμβάντος. . . . Στοιχεία δράσης * Βελτίωση της πολιτικής διατήρησης περιουσιακών στοιχείων έτσι ώστε η τρέχουσα ενεργή έκδοση δεν υπόκειται ποτέ σε έξωση.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Η βραδύτητα μπορεί να προκαλέσει κάποιο από τα παρακάτω συμπτώματα: - Οι σωλήνες δεν ξεκινούν - Καθυστέρηση στην εκτέλεση - Σωλήνες που ακυρώνονται λόγω των χρονικών ορίων
Το cloud provider μας αντιμετωπίζει ένα ενεργό περιστατικό και παρακολουθούμε.
Συνεχίζουμε να ερευνούμε αυτό το ζήτημα.
Ο πάροχος cloud μας επιβεβαίωσε ένα συνεχιζόμενο περιστατικό που επηρεάζει πολλαπλές περιοχές. Οι αγωγοί Harness δεν έχουν παρουσιάσει αποτυχίες ως αποτέλεσμα, αν και ορισμένοι χρήστες μπορεί να συνεχίσουν να βιώνουν βραδύτητα. Παρακολουθούμε στενά την κατάσταση και θα παράσχουμε ενημερώσεις καθώς θα γίνονται διαθέσιμες περισσότερες πληροφορίες.
Παρατηρούμε βελτιωμένες κενές λειτουργίες σε όλο το διοικητικό συμβούλιο μετά τη διόρθωση που υλοποιείται από τον πάροχο cloud μας. Συνεχίζουμε να παρακολουθούμε στενά την κατάσταση και θα παράσχουμε περαιτέρω ενημερώσεις, όπως δικαιολογείται. Παρατηρήσαμε κάποιες κολλημένες εκτελέσεις για CI για δύο πελάτες, τις οποίες ερευνούμε
Το περιστατικό λύθηκε.
# Περίληψη Στις 20 Αυγούστου 2026, αρχίζοντας περίπου στις 15:00 UTC, η πλατφόρμα Harness γνώρισε εκτεταμένη υποβάθμιση των επιδόσεων σε όλα τα περιβάλλοντα παραγωγής. Οι εκτελέσεις αγωγών που κανονικά ολοκληρώνουν σε περίπου δύο λεπτά χρειάστηκαν επτά με δέκα λεπτά. Η συνεχής παράδοση, η συνεχής ολοκλήρωση, η ενορχήστρωση των αγωγών και η Διαχείριση και Πειραματισμός Χαρακτηριστικών επηρεάστηκαν. Το Google Cloud Platform γνώρισε ένα επεισόδιο πολλαπλών προϊόντων στην περιοχή us-west1 που επηρεάζει Bigtable, Compute Engine, Google Kubernetes Engine, και επίμονη-δίσκο I/O. Η υποδομή παραγωγής Harness λειτουργεί σε επίμονους δίσκους σε αυτή την περιοχή. Η υποβάθμιση αύξησε τη λανθάνουσα λειτουργία της βάσης δεδομένων από περίπου 2 ms σε πάνω από 10 ms στο 95ο εκατοστημόριο, το οποίο με τη σειρά του προκάλεσε καθυστέρηση στην επεξεργασία μηνυμάτων-queue και πολλαπλασιάζεται σε κάθε υπηρεσία που εξαρτάται από την έγκαιρη πρόσβαση στη βάση δεδομένων. # Σύγκρουση Αυτό ήταν μια υποβάθμιση, όχι μια διακοπή. Οι αγωγοί συνέχισαν να εκτελούν και να ολοκληρώνουν επιτυχώς σε όλη τη διάρκεια · ήταν αργοί αντί να αποτύχουν. Κανένα στοιχείο δεν χάθηκε, και καμία εργασία του πελάτη δεν έπεσε ως αποτέλεσμα αυτού του συμβάντος. # ** Αιτίες για τα σκουπίδια ** Η υποδομή παραγωγής Harness στα επηρεαζόμενα περιβάλλοντα λειτουργεί σε επίμονους δίσκους Google Cloud Platform στην περιοχή us-west1. Όταν αυτό το στρώμα αποθήκευσης υποβαθμίστηκε, το αποτέλεσμα εξαπλώθηκε μέσω της πλατφόρμας σε μια προβλέψιμη αλυσίδα: ** Επίμονη αποδόμηση του δίσκου I/O σε εμάς-δυτικά1.** Το Google Cloud Platform γνώρισε ένα επεισόδιο πολλαπλών προϊόντων που επηρέασε το Bigtable, το Compute Engine, το Google Kubernetes Engine και την επίμονη απόδοση του δίσκου. Αυτό ήταν μια αποτυχία της υποδομής στο περιβάλλον του παρόχου, έξω από τον έλεγχο του Harness. ** Προληπτικές ενέργειες ** Αν και Harness δεν μπορεί να αποτρέψει μια βλάβη υποδομής πάροχο σύννεφο. Οι ενέργειες που ακολουθούν έχουν ως στόχο να ανιχνεύσουν ένα πιο γρήγορο και να είναι καλύτερα τοποθετημένα για να δράσουν σε αυτό. \"Δράση\"
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Το θέμα έχει εντοπιστεί και υλοποιείται μια λύση.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
Περίληψη Στις 20 Αυγούστου 2026, μεταξύ 10:24 και 14:55 UTC, ένα υποσύνολο του FME γράφει απέτυχε. Γράμματα από το FME UI και γράφει με Harness πρόσβαση tokens \(PATs και SATS\) δεν επηρεάστηκαν. Η αξιολόγηση της σημαίας συνέχισε να λειτουργεί κανονικά. Το ζήτημα μετριάστηκε με την επαναφορά μιας πρόσφατης αλλαγής ταυτοποίησης σε μια υπηρεσία κοινής διακυβέρνησης, και επηρεάζεται γράφει επέστρεψε στο κανονικό από 14:55 UTC. Κατάσταση: [https://status.harness.io/incidents/rhthgm7d5dkz] (https://status.harness.io/incidents/rhthgm7d5dkz) Αιτία ρίζας Μια αλλαγή στον τρόπο με τον οποίο μια υπηρεσία κοινής διακυβέρνησης πιστοποίησε τις εισερχόμενες κλήσεις είχε ως αποτέλεσμα να απορριφθεί κάποια FME. Αυτές οι εγγραφές χρησιμοποιούσαν διαπιστευτήρια υπηρεσίας προς υπηρεσία που η υπηρεσία διακυβέρνησης δεν μπορούσε πλέον να επαληθεύσει μετά την αλλαγή. Η FME αντιμετωπίζει μια αποτυχία διακυβέρνησης στον πελάτη με HTTP 499, την ίδια κατάσταση που χρησιμοποιείται όταν μια πολιτική διακυβέρνησης αρνείται εκ προθέσεως μια αλλαγή. Επειδή το 499 είναι μια έγκυρη, αναμενόμενη απάντηση σε αυτή την πορεία άρνησης, οι αποτυχίες δεν έμοιαζαν με διακοπή στις ειδοποιήσεις μας, και το περιστατικό εντοπίστηκε από αναφορές πελατών και όχι με εσωτερική ανίχνευση. Σύγκρουση * Ένα υποσύνολο του FME γράφει απέτυχε κατά τη διάρκεια του παραθύρου, κυρίως αυτά που γίνονται χρησιμοποιώντας τα κληροδοτημένα πλήκτρα Split API ή τον προγραμματισμό της αίτησης αλλαγής. * Οι εγγραφές που έγιναν από το FME UI δεν επηρεάστηκαν. * Γράφει χρησιμοποιώντας Harness πρόσβαση tokens - (PATs και SATs\) δεν επηρεάστηκαν. * Runtime σημαία αξιολόγηση συνεχίστηκε κανονικά. * Δεν παρατηρήθηκε απώλεια δεδομένων. Οι αποτυχημένες εγγραφές δεν ισχύουν. Αποκατάσταση Επανέστρεψε την αλλαγή ταυτότητας διακυβέρνησης-υπηρεσίας. Επηρεασμένος γράφει επέστρεψε στο κανονικό αμέσως. Αντικείμενα δράσης Για να αποτραπεί η επανάληψη τέτοιων θεμάτων, * Harness θα επιστρέψει ένα διακριτό σφάλμα \(όχι 499\) όταν μια γραφή αποτυγχάνει, επειδή η διακυβέρνηση δεν μπορούσε να αξιολογηθεί, έτσι δεν συγχέεται με μια εσκεμμένη άρνηση πολιτικής. * Προσθήκη ειδοποίησης σχετικά με την ίδια την αξιολόγηση διακυβέρνησης, αντί να βασίζεται στον κωδικό κατάστασης που αντιμετωπίζει ο πελάτης. * Επέκταση υποστήριξης ταυτοποίησης για αξιολογήσεις πολιτικής. * Επέκταση αυτοματοποιημένης κάλυψης για πρόσθετα σενάρια εγγραφής.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Συνεχίζουμε να ερευνούμε αυτό το ζήτημα.
Το θέμα έχει εντοπιστεί και υλοποιείται μια λύση.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Συνεχίζουμε να παρακολουθούμε για τυχόν περαιτέρω ζητήματα.
Το περιστατικό λύθηκε.
**Περίληψη ** Στις 19 Αυγούστου 2026 μεταξύ 12:35 και 17:29 UTC, η υπηρεσία ασφάλειας εφαρμογών Harness παρουσίασε σημαντική διαταραχή που επηρέασε τόσο την κονσόλα που αντιμετωπίζει ο πελάτης όσο και τον αγωγό κατάποσης δεδομένων στις περιοχές παραγωγής SaaS και US1. ** Αιτία Root ** Η εσωτερική υπηρεσία διαμόρφωσης που παρέχει ρυθμίσεις χρόνου λειτουργίας σχεδόν σε κάθε άλλο συστατικό υπερφορτώθηκε και μπήκε σε έναν επαναλαμβανόμενο κύκλο επανεκκίνησης. Επειδή τόσες πολλές υπηρεσίες εξαρτώνται από αυτό, τα αποτελέσματα ήταν ευρεία: σελίδες κονσόλας, όπως πολιτικές προστασίας, απόψεις στάσης, αρχεία καταγραφής δραστηριοτήτων, API απογραφή, και προσαρμοσμένη πολιτική απέτυχε να φορτώσει ή χρονομέτρηση, και κατάντη επεξεργασία σταματήσει, ενώ περιμένει για τη διαμόρφωση δεν θα μπορούσε να αποκτήσει. # ** Επιπτώσεις πελατών ** Η υστέρηση των καταναλωτών αυξήθηκε κατά την ομαλοποίηση, την ομαδοποίηση, την ανίχνευση ανωμαλιών, την παραγωγή και τα σχετικά στάδια επεξεργασίας. ** Απαγόρευση ** Αρκετοί ενδιάμεσοι μετριασμοί επιπλέον ΚΜΕ και μνήμη, χαλαροί υγειονομικοί έλεγχοι κατώτατα όρια, μια επανεκκίνηση της βάσης δεδομένων, και μια μεγαλύτερη πισίνα σύνδεσης βελτιώθηκε το ζήτημα. Απενεργοποιώντας το νέο χαρακτηριστικό και στις δύο πληγείσες περιοχές, αποκαταστάθηκε απότομα και επισφαλώς. Το περιστατικό επιλύθηκε στις 17:29 UTC. ** Προληπτικές ενέργειες ** Οι ακόλουθες ενέργειες δεσμεύονται και εντοπίζονται εσωτερικά μέχρι την ολοκλήρωση. Το χαρακτηριστικό που πυροδότησε αυτό το περιστατικό παραμένει απενεργοποιημένο και δεν θα ενεργοποιηθεί εκ νέου έως ότου ολοκληρωθεί και επικυρωθεί η παρακάτω εργασία. \"Δράση\"
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
We are currently investigating a Harness component that is experiencing issues. We are working to identify the cause and restore normal operations as soon as possible.
Συνεχίζουμε να ερευνούμε αυτό το ζήτημα.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
Περίληψη Οι πελάτες σε Prod1, Prod2, και Prod3 \(US\) συστάδες παρουσίασαν αποτυχίες κατά τη φόρτωση SEI 2.0 ταμπλό στις 6 Αυγούστου 2026, από 7:22 ΠΜ PDT έως 9:03 ΠΜ PDT. Πελάτες που καλούν το SEI 2.0 API επίσης παρουσίασαν παρόμοιες αποτυχίες. Δεν χάθηκαν δεδομένα πελατών, και η κατάποση όλων των δεδομένων ενσωμάτωσης συνέχισε να λειτουργεί αδιάκοπα. Οι πελάτες SEI που χρησιμοποιούν το 1.0 δεν επηρεάστηκαν. Αιτία ρίζας Το περιστατικό προκλήθηκε από εξάντληση πόρων στους κόμβους που εξυπηρετούσαν ερωτήματα. Αυτή η υποβάθμιση των πόρων αναπτύχθηκε σε ένα μοτίβο που δεν διέσχισε τα υφιστάμενα όρια συναγερμού μας αρκετά νωρίς ώστε να παρέχει επαρκή προειδοποίηση ή να επιτρέπει μετριασμό πριν από τον αντίκτυπο των πελατών. Σύγκρουση Οι πελάτες στο Prod1, Prod2, και Prod3 \(US\) συστάδες δεν ήταν σε θέση να φορτώσουν SEI 2.0 ταμπλό κατά τη διάρκεια του παραθύρου συμβάντος. **Dιάρκεια: ** 6 Αυγούστου 2026, 7:22 ΠΜ PDT – 9:03 ΠΜ PDT \(~1 ώρα 41 λεπτά\) Τι δεν επηρεάστηκε; * Κατάποση και επεξεργασία δεδομένων * SEI 1.0 πελάτες * Ενσωματώσεις και ροές μεταδεδομένων Δεν χάθηκαν δεδομένα πελατών. . . . Αποκατάσταση Κατά την αναγνώριση της βασικής αιτίας, η ομάδα μας έλαβε άμεση διορθωτική δράση προσθέτοντας ικανότητα για την αποκατάσταση των προσβεβλημένων συστημάτων. Οι υπηρεσίες ανακτήθηκαν πλήρως, και όλα τα ταμπλό ξανάρχισαν την κανονική λειτουργία στις 9:03 ΠΜ PDT. . . . Στοιχεία δράσης Για να αποτρέψει από τέτοια θέματα που συμβαίνουν και πάλι, Harness είναι / έχει Για να αποφευχθεί η επανάληψη αυτού του ζητήματος εφαρμόστηκαν προδρομικά πρόσθετες ενημερώσεις δυναμικότητας Ενισχυμένη παρακολούθηση και ειδοποίηση Επιπλέον παρακολούθηση και προειδοποίηση έχουν τεθεί σε εφαρμογή για τον εντοπισμό ανωμαλιών νωρίς, εστιάζοντας σε έναν κορυφαίο δείκτη, ο οποίος σε αυτή την περίπτωση ήταν η εξάντληση της δεξαμενής νημάτων, πριν μπορέσουν να επηρεάσουν τη διαθεσιμότητα του ταμπλό και την απόδοση δεδομένων. Συνάρτηση συστήματος σε εξέλιξη Συνεργαζόμαστε με τον προμηθευτή μας για να εφαρμόσουμε ένα έμπλαστρο για να διορθώσουμε αυτό και παρόμοια ζητήματα εντελώς.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Παρακολουθούμε τους εγκλωβισμένους αγωγούς στο προϊόν 2. Οι νέες εκτελέσεις περνούν καθώς παρακολουθούμε συνεχώς τις υπηρεσίες.
Παρακολουθούμε τους εγκλωβισμένους αγωγούς στο προϊόν 2. Για τους πελάτες που βλέπουν ακόμα κολλημένους αγωγούς, σας ζητάμε να ματαιώσετε και να ενεργοποιήσετε εκ νέου.
Το περιστατικό λύθηκε.
\"Περίληψη\" Στις 6 Αυγούστου 2026 \(πρωί PDT\), ορισμένοι πελάτες που εκτελούσαν αγωγούς στο περιβάλλον παραγωγής Prod2 παρατήρησαν εκτελέσεις αγωγών που σταμάτησαν να σημειώνουν πρόοδο — στάδια που δεν προχώρησαν και δεν παρήγαγαν περαιτέρω ενημερώσεις για την παραγωγή ή την κατάσταση. Το ζήτημα αναφέρθηκε από επηρεαζόμενους πελάτες. Οι μηχανικοί του Harness εντόπισαν την αιτία, μείωσαν την πρόσκρουση και οι εκτελέσεις των αγωγών επέστρεψαν στην κανονική λειτουργία. Το ζήτημα προκλήθηκε από μια έκφραση αυτοαναφορικού αγωγού. Ένα webhook Git ενεργοποίησε έναν αγωγό που αναφερόταν στο περιεχόμενο του ωφέλιμου φορτίου webhook, και το ίδιο το ωφέλιμο φορτίο περιείχε περαιτέρω αντίγραφα της ίδιας έκφρασης. Κατά συνέπεια, κάθε γύρος ψηφίσματος έκφρασης παρήγαγε περισσότερες εκφράσεις για την επίλυση, διπλασιάζοντας το ποσό της εργασίας κάθε φορά. Το γεγονός αυτό εξάντλησε τους πόρους του σεμιναρίου για την επεξεργασία αυτής της εκτέλεσης, καθώς και άλλες εκτελέσεις που είχαν ανατεθεί στην ίδια περίπτωση δεν ήταν σε θέση να προοδεύσουν όσο βρισκόταν σε αυτή την κατάσταση. Impact ** Impact ** Κατά τη διάρκεια του παραθύρου συμβάντος \ (περίπου 6:11 ΠΜ έως 11:23 ΠΜ PDT στις 6 Αυγούστου 2026\): * Ορισμένες εκτελέσεις αγωγών πελατών στο Prod2 καθυστέρησαν τη μέση εκτέλεση και δεν σημείωσαν περαιτέρω πρόοδο. * Οι επηρεαζόμενες εκτελέσεις δεν παρήγαγαν κανένα νέο βήμα εξόδου ή ενημερώσεις κατάστασης, και έπρεπε να ματαιωθεί και να επαναληφθεί μετά τον μετριασμό. * Η συμπεριφορά περιοριζόταν σε εκτελέσεις που διεκπεραιώθηκαν από την θιγόμενη περίπτωση παροχής υπηρεσιών — οι αγωγοί που χειρίζονταν άλλες περιπτώσεις εξακολούθησαν να εκτελούνται κανονικά. Δεν υπήρξε ** απώλεια δεδομένων **. Οι ορισμοί των αγωγών, το ιστορικό εκτέλεσης και η αποθηκευμένη κατάσταση δεν επηρεάστηκαν. Η πλειοψηφία των αγωγών στο Prod2 συνέχισε να εκτελεί επιτυχώς καθ' όλη τη διάρκεια του συμβάντος· ο πρωταρχικός αντίκτυπος ήταν ότι ορισμένες εκτελέσεις κατά την πτήση δεν μπορούσαν να ολοκληρωθούν και έπρεπε να επαναλειτουργήσουν μόλις μετριαστεί το ζήτημα. Αιτίες για τα σκουπίδια Οι αγωγοί Harness υποστηρίζουν εκφράσεις που επιλύονται στο χρόνο λειτουργίας — για παράδειγμα, μια έκφραση που εισάγει το περιεχόμενο του ωφέλιμου φορτίου ζεύξης Git που ενεργοποίησε τον αγωγό. Στην περίπτωση αυτή, ένα μήνυμα δέσμευσης Git περιείχε το κυριολεκτικό κείμενο της ίδιας της έκφρασης ωφέλιμο φορτίο, δύο φορές, και ο αγωγός ανέφερε την ίδια έκφραση ωφέλιμου φορτίου. Επειδή το μήνυμα της δέσμευσης αποτελεί μέρος του ωφέλιμου φορτίου του webhook, η επίλυση της έκφρασης εισήγαγε ολόκληρο το ωφέλιμο φορτίο — περιλαμβανομένων και των δύο κυριολεκτικών αντιγράφων της έκφρασης που μεταφέρει το μήνυμα της δέσμευσης. Στη συνέχεια, τα νέα αυτά αντίγραφα αντιμετωπίστηκαν ως εκφράσεις προς επίλυση, και κάθε πέρασμα εισήγαγε δύο ακόμη πλήρη αντίγραφα του ωφέλιμου φορτίου. Το μέγεθος της αξίας που επεξεργάζεται, και το έργο που απαιτείται για την επεξεργασία της, ως εκ τούτου διπλασιάστηκε σε κάθε πάσα και αυξήθηκε εκθετικά παρά συγκλίνει. Harness έχει μια προστασία που προορίζεται να σταματήσει ακριβώς αυτό: ανάλυση έκφρασης οριοθετείται από ένα μέγιστο βάθος φωλιάσματος, πέρα από το οποίο η ανάλυση σταματά και ο αγωγός αποτυγχάνει με ένα σαφές λάθος. Ένα ελάττωμα αυτής της διασφάλισης σήμαινε ότι το όριο δεν εφαρμοζόταν σε αυτή τη συγκεκριμένη περίπτωση αυτοαναφοράς, οπότε η επίλυση συνεχίστηκε ανεξέλεγκτη. Η ανάλυση της έκφρασης συνδέεται με τα νήματα που ξεκινούν τα βήματα του αγωγού. Καθώς κάθε πέρασμα κατανάλωνε προοδευτικά περισσότερη μνήμη και CPU χωρίς ποτέ να ολοκληρωθεί, η περίπτωση υπηρεσίας που εκτελούσε αυτή την εργασία σταμάτησε να κάνει πρόοδο, και κάθε εκτέλεση που είχε ανατεθεί σε αυτή την περίπτωση καθυστέρησε — κάτι που ανέφεραν οι πελάτες. ¶ ¶ ¶ ¶ Η Harness ολοκλήρωσε τα ακόλουθα άμεσα βήματα μετριασμού: * Αναγνωρίστηκε ο αγωγός και το πρότυπο έκφρασης που είναι υπεύθυνο για το δραπέτη ψήφισμα. * Σταμάτησε την επηρεαζόμενη περίπτωση υπηρεσίας ώστε να μην χρειαστεί περαιτέρω εργασία. Οι εναπομείναντες υγιείς περιπτώσεις μάζευαν και επεξεργάζονταν εκτελέσεις σε ουρές κανονικά. * Επιβεβαιώθηκε ότι οι εκτελέσεις του αγωγού επέστρεψαν στο φυσιολογικό και έκλεισαν το περιστατικό. Αυτές οι ενέργειες αποκατέστησαν την κανονική συμπεριφορά εκτέλεσης του αγωγού και διέλυσαν τον αντίκτυπο που αντιμετώπιζε ο πελάτης. ** Στοιχεία δράσης ** Για να μειωθεί ο κίνδυνος επανεμφάνισης και να βελτιωθεί η ανίχνευση, οι ακόλουθες δράσεις βρίσκονται σε διάφορα στάδια υλοποίησης: * Καθορίστε το ελάττωμα στην έκφραση βάθος και ανίχνευση βρόχου-προφύλαξη έτσι ώστε αυτο-αναφορικές εκφράσεις πιάνονται και αποτυγχάνουν γρήγορα με ένα σαφές λάθος αντί της κατανάλωσης πόρων χωρίς δέσμευση. * Αποτρέπουμε τις εκφράσεις payload να επιλυθούν από το περιεχόμενο του payload ενεργοποίησης, αφαιρώντας εντελώς την αυτοαναφορική διαδρομή. * Σφίξε το μέγιστο βάθος φωλεοποίησης έκφρασης και αξιολόγησε σαφή ανίχνευση βρόχου εκτός από το υπάρχον όριο βάθους. * Ενισχύστε τις αυτοματοποιημένες δοκιμές σε περιβάλλοντα προ-παραγωγής που αναπαράγουν μοτίβα αυτο-αναφορικής έκφρασης και επαληθεύστε ότι η προστασία τους ανιχνεύει και τους σταματά. * Προσθέστε την παρακολούθηση για αυτό το μοτίβο σε εκτελέσεις αγωγών, έτσι ώστε να ανιχνεύεται προληπτικά.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
We are currently investigating this issue.
We are continuing to investigate this issue.
We have identified the issue and started to implement the fix , prod2 is restored.
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
This incident has been resolved.
# Executive Summary On August 4, 2026, between approximately 3:36 PM and 9:00 PM IST, customers using Infrastructure as Code Management \(IaCM\) on Prod0 and Prod1 were unable to access the Variable Sets settings page. The page rendered blank with no error message, and customers with Variable Sets attached to their workspaces could not view or manage them for the duration of the incident. Prod2, Prod3, and EU1 were not affected. Separately, during the same window, a scheduled maintenance action caused the IaCM settings tab to temporarily disappear across all environments. This was identified and reversed within the incident bridge call before significant customer impact occurred. We deployed a hotfix that restored full access to the Variable Sets page on Prod0 and Prod1 the same evening, and we are implementing permanent safeguards described below to prevent this class of issue from recurring. # Impact * Customers with the Variable Sets feature enabled on Prod0 and Prod1 were unable to view or manage Variable Sets for approximately 5–6 hours. * No data was lost or corrupted, this was a UI routing failure only; underlying Variable Sets data and configuration were not affected. * Prod2, Prod3, and EU1 were not affected by this issue. * A secondary issue, a scheduled feature flag operation caused the IaCM settings tab to temporarily disappear across all environments during the incident bridge call. This was identified and reversed within minutes. External customer exposure for this secondary issue is still being confirmed. # Root Cause A platform routing change released on July 18, 2026 updated how IaCM settings pages are resolved in the user interface. As part of that change, any settings page that had not been explicitly re-registered in the new routing structure became unreachable. The Variable Sets page had not been re-registered under the new routing structure, making it inaccessible in the environments where the routing change had been deployed — Prod0 and Prod1. Because the failure occurred at the routing layer rather than within the page itself, the page rendered blank with no visible error rather than showing a clear failure message. # Remediation ## Immediate We deployed a hotfix that re-registered the Variable Sets page in the updated routing structure, restoring access for all affected customers on Prod0 and Prod1. ## Permanent We are adding automated end-to-end tests that navigate to settings pages with relevant feature flags enabled, configured as a required gate in our release pipeline. We are also documenting and enforcing the routing constraint through static analysis so that settings pages are never inadvertently left out of the routing structure during future platform changes. # Action Items To prevent such issues from happening again, 1. Enhance automated tests, that navigate to settings pages with relevant feature flags enabled, configured as a blocking gate in the release pipeline, so this class of regression is caught before it reaches production. 2. Establish an explicit checklist step for future platform-wide architectural changes that verifies all existing settings pages remain accessible in the updated routing structure before the change is promoted to production.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Το θέμα έχει εντοπιστεί και υλοποιείται μια λύση.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
# **Περίληψη ** Μεταξύ 25 Ιουλίου και 4 Αυγούστου 2026, ταμπλό εκτέλεσης αγωγών και σελίδες επισκόπησης στο Harness Prod 2 και Prod 3 συστάδες παρουσίαζε δεδομένα που ήταν μεταξύ πίσω από πραγματικό χρόνο. Οι ίδιοι οι αγωγοί συνέχισαν να κατασκευάζουν, να αναπτύσσουν και να εκτελούν κανονικά καθ' όλη τη διάρκεια· το ζήτημα περιορίστηκε στο πόσο γρήγορα αντιγράφονταν τα αρχεία εκτέλεσης στη βάση δεδομένων που εξυπηρετεί την αναφορά και τις απόψεις του ταμπλό. ** Δεν χάθηκαν δεδομένα πελατών. ** Κάθε προσβεβλημένη εγγραφή παρέμεινε αποθηκευμένη και επαναπροβλήθηκε στο datastore ανάλυσης μόλις αφαιρέθηκε ο υποκείμενος περιορισμός. Η Harness μετανάστευσε τις πληγείσες συστάδες σε μια οριζόντια κλιμακούμενη, υποστηριζόμενη από την ουρά έκδοση του συστατικού αντιγραφής την 1η Αυγούστου 2026 και ολοκλήρωσε στοχευμένες ανακλάσεις δεδομένων για όλους τους θιγόμενους λογαριασμούς. # ** Αιτίες για τα σκουπίδια ** Η Harness διατηρεί ένα στοιχείο δέσμευσης δεδομένων αλλαγής που αναπαράγει συνεχώς αρχεία εκτέλεσης αγωγών από το κύριο επιχειρησιακό datastore σε ένα ξεχωριστό datastore χρονοσειρών βελτιστοποιημένο για ταμπλό και ερωτήματα αναφοράς. Οι πίνακες διαβάζονται αποκλειστικά από το datastore της αναλυτικής. Όταν η αντιγραφή πέφτει πίσω, τα ταμπλό καθιστούν μια ακριβή αλλά παλαιότερη άποψη του κόσμου, ενώ η ίδια η εκτέλεση δεν επηρεάζεται. Αυτό προκλήθηκε από απότομη, συνεχή αύξηση του όγκου της βάσης δεδομένων γράψτε από μια άλλη μονάδα πλατφόρμα Harness μοιράζονται την ίδια διαδρομή αντιγραφής ξεπέρασε το ανώτατο όριο διέλευσης της παλαιότερης, ενιαία έκδοση του εν λόγω συστατικού που λειτουργεί ακόμα σε Prod 2 και Prod 3. Ένα backlog σχηματίστηκε και μεγάλωσε. ** Προληπτικές ενέργειες ** Ο Harness έχει ολοκληρώσει ή δεσμευτεί στις ακόλουθες ενέργειες για την πρόληψη τέτοιων θεμάτων. \"Δράση\"
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Το θέμα έχει εντοπιστεί και υλοποιείται μια λύση.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
# **Summary** On July 31, 2026, artifact uploads performed through pipeline in the EU1 cluster began failing with an authentication error. Uploads initiated manually \(outside of a pipeline\) were not affected, and the ability to retrieve existing artifacts \(downloads\) was also unaffected — this was isolated to the specific pipeline upload path in one cluster. # **Impact** * Artifact uploads performed through pipeline in the EU1 cluster failed with an authentication error for approximately 4 hours and 34 minutes. * Retrieving existing artifacts \(downloads\) was not affected. * Manually uploading artifacts outside of a pipeline was not affected. * Other clusters/regions were not affected by this issue. # **Root Cause** The component responsible for handling pipeline-based artifact uploads is distributed as a container image. In the EU1 cluster, this image is retrieved from an internal registry that mirrors a public image source; in other clusters, the same image is retrieved directly from the public source. A publishing error in our release process caused a new build of this component to be published using a version label that was already in use, rather than being assigned a new, unique version. As a result, two different images ended up associated with the same version label in the public source. Our internal registry mirrors images from the public source via an automated replication process. Because of how that replication was triggered, it copied the original \(earlier\) image associated with that version label rather than the corrected one. This meant the EU1 cluster — which pulls from the internal mirror — ended up running a different, defective image than other clusters, which pull directly from the public source and therefore received the corrected image. The defective image contained an authentication issue that caused pipeline uploads to fail. # **Mitigation** * Reverted the affected account to the last known-good version of the upload component, immediately restoring pipeline uploads. * Published a corrected, permanent version of the component to resolve the issue across all clusters. # **Next steps** * Fix the upload step to remove the underlying container-related defect that made this failure mode possible. * Update our release pipeline for this component so that publishing an image can never overwrite an existing version — every publish must create a new, distinct version going forward.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Περίληψη - Αντιμετωπίζουμε διαλείποντα προβλήματα συνδεσιμότητας δικτύου με το Build VM να αδυνατεί να συνδεθεί με εξωτερικούς πόρους. Αυτή τη στιγμή ερευνούμε το θέμα.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Συνεχίζουμε να παρακολουθούμε για τυχόν περαιτέρω ζητήματα.
Το περιστατικό λύθηκε.
## Summary Starting on August 4, 2026, CI runners in the us-west1 and us-central1 regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services such as GitHub and Bitbucket over outbound network gateways. ## Impact * CI runners in the affected regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services \(e.g., GitHub, Bitbucket\) over our outbound network gateways. * The issue was intermittent rather than constant — connections succeeded under normal load, and failures clustered during periods of high outbound traffic volume. * No data was lost or corrupted. This was a network-connectivity and capacity issue, not a data-integrity issue. * us-west1 and us-central1 were the affected regions; other regions were not impacted by this issue. ## Root Cause Our load balancer distributes outbound traffic across multiple NAT gateways using a hashing method based on connection details \(source/destination address and port\). For any single connection, these details stay constant for that connection's lifetime. We had a sustainted traffic surge for a few seconds which congested the gateways ## Action Items To prevent such issues from happening again Harness will, Increase outbound connection capacity on our NAT gateways by provisioning additional external network interfaces, giving each gateway a substantially larger pool of connections it can serve concurrently..
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Συνεχίζουμε να ερευνούμε αυτό το ζήτημα.
Το θέμα έχει εντοπιστεί και υλοποιείται μια λύση.
Συνεχίζουμε να εργαζόμαστε πάνω σε μια λύση για αυτό το ζήτημα.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Συνεχίζουμε να παρακολουθούμε για τυχόν περαιτέρω ζητήματα.
Το περιστατικό λύθηκε.
# Summary During a recent production deployment, a defect in our internal deployment tooling caused two critical services to run with incorrect, non-production configuration values in our production environment This led to a related set of four distinct symptoms: incorrect configuration behavior, intermittent login/access failures, a filestore access issue affecting one customer environment, and delayed pipeline status updates in the UI. We have identified and are implementing a permanent fix for the underlying configuration defect, and have already put in place resource and capacity changes that resolve the UI delay symptom. At no point during this incident were pipeline executions themselves lost, corrupted, or left in a stuck state. Where execution behavior was affected, it was limited to delays in status visibility, not in the underlying processing. # Incident Details ## Incorrect Production Configuration Values Applied Our engineering team confirmed a defect in the Service Manager deployment pipeline that caused certain production services to be deployed using configuration values intended for a different environment, rather than the correct production configuration. **Root Cause** The service responsible for fetching configuration overrides during deployment queries an internal API that returns a maximum of 1,000 results per request. The total number of services in the environment recently grew beyond that limit. As a result, any service beyond the first 1,000 returned was not included in the response, and the deployment pipeline silently fell back to default configuration values for those services. This is a confirmed pagination defect in the deployment tooling, not an issue with the configuration values themselves. **Resolution** Engineering has confirmed the mechanism and is implementing a permanent fix to remove this limit-related gap in the deployment pipeline. ## Intermittent Login / Access Failures During the Service Manager deployment referenced above, some users experienced intermittent login or access failures. Under normal operation, previously running instances should continue serving traffic without interruption while a new deployment is in progress. In this incident, that fallback behavior did not occur as expected, contributing to access failures during the deployment window. ## Filestore Access Issue A filestore access issue was identified that was specific to the Prod-3 environment and affected a single customer's environment. **Root Cause** This is related to an IAM / storage-bucket permission configuration on Service Manager, potentially triggered by rollback activity. ## Delayed Pipeline Execution Status Updates in UI Some users observed that the pipeline execution graph in the UI was slow to refresh and did not reflect the latest status promptly. Importantly, this was a visibility delay only: there was no impact to actual pipeline executions, and no executions were stuck or failed as a result of this issue. **Root Cause** The pipeline execution graph relies on a message stream \(the orchestration log\) to receive status updates. During the incident window, consumer processing of this stream fell behind \(high consumer lag\), which delayed how quickly status updates reached the UI. This was caused by the fact that the underlying database was in the middle of a planned scaling operation at the same time, and a traffic spike during that window further exacerbated the delay. Users experienced this as apparent pipeline slowness, even though the underlying executions were running normally. **Resolution** We have increased resource capacity for the affected components to maintain more than 50% spare headroom going forward, reducing sensitivity to similar load spikes. This change has been implemented and is currently being validated as part of longer-term hardening for this part of the platform. # Impact Summary * Service Manager and License Manager ran with incorrect configuration values in the Prod-1 and Prod-3 environments. * Some users experienced intermittent login or access failures during the affected deployment window. * One customer environment in Prod-3 experienced a filestore access issue. * Users across affected environments saw delayed pipeline execution status updates in the UI; underlying pipeline executions continued to run correctly and were not lost, stuck, or corrupted. # Preventive Actions The following corrective and preventive actions have been identified. | **Corrective / Preventive Action** | | --- | | Correct the pagination limit in the configuration-lookup service so that all services are returned and evaluated, regardless of total count. | | Add safeguards so that a service which cannot retrieve its configuration fails safely \(e.g. alerts and blocks the deployment\) rather than silently falling back to non-production defaults. | | Increase Postgres and messaging-pipeline resource headroom \(target: greater than 50% spare capacity\) to reduce sensitivity to concurrent load and scaling events. | _We recognize the impact this incident had across multiple areas of the platform and appreciate your patience as we work through a complete resolution._
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Ερευνούμε ένα θέμα που επηρεάζει τα ταμπλό του AIDI. Οι χρήστες μπορεί να βιώσουν αυξημένο χρόνο φόρτωσης ή διαλείπουσες αστοχίες κατά την πρόσβαση σε ταμπλό. Η ομάδα μας εργάζεται ενεργά για να εντοπίσει τη βασική αιτία και να αποκαταστήσει την κανονική απόδοση. Θα παρέχουμε ενημερώσεις καθώς θα γίνονται διαθέσιμες περισσότερες πληροφορίες.
Το θέμα έχει εντοπιστεί και υλοποιείται μια λύση.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
## Summary Customers on Prod1, Prod2, and Prod3 clusters experienced intermittent widget load failures and increased load times when accessing AIDI 2.0 dashboards on July 22, 2026. Not all widgets were affected simultaneously the issue manifested as sporadic failures rather than a full outage. No customer data was lost. SEI 1.0 customers were not impacted. ## Root Cause Over time, a routine database maintenance process failed to run on certain tables in our analytics database, causing those tables to accumulate a large volume of internal metadata used to track deleted records. When the database planned queries against these tables, it loaded all of this accumulated metadata into memory, causing memory usage on the affected nodes to spike repeatedly. These repeated spikes triggered an automatic safety mechanism that restarts a node when it detects excessive memory pressure, and the affected nodes began restarting in a loop as a result. This caused intermittent, degraded query performance on AIDI 2.0 dashboards for the duration of the incident. ## Impact Customers on Prod1, Prod2, and Prod3 clusters may have experienced intermittent widget load failures or increased load times on AIDI 2.0 dashboards. **Duration:** July 22, 2026, 07:58 PDT – 16:16 PDT \(~8 hours 18 minutes\), with intermittent widget failures; system was restarted and under active monitoring from 08:25 PDT onward. ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the issue, the affected database nodes were restarted at 08:25 PDT, which restored initial stability. We continued to monitor the system closely, and when intermittent degradation was still observed afterward, we applied several additional fixes: * Adjusted database configuration settings to limit the amount of memory used for processing accumulated metadata, and tuned query-planning settings to reduce memory pressure. * Ran cleanup jobs to reduce the backlog of accumulated metadata on the affected tables. * Increased capacity on the affected database nodes to provide additional headroom. These changes progressively stabilized the system, and the incident was fully resolved at 16:16 PDT. ## Action Items To prevent recurrence, we are implementing the following: 1. We have upgraded the backend which includes underlying improvements that handle memory spikes caused by excessive delete files. 2. We have rolled out automated compaction jobs for newly introduced tables to prevent delete file accumulation going forward.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Το θέμα έχει εντοπιστεί και υλοποιείται μια λύση.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Το περιστατικό λύθηκε.
# Περίληψη Στις 17 Ιουλίου 2026, μετά από μια ανάπτυξη κώδικα ρουτίνας, οι πελάτες σε παλαιότερες εκδόσεις ανάθεσης \(858xx και κάτω\) άρχισαν να βιώνουν καθυστερημένα CI οικοδομήματα σε Harness Cloud-hosted builds χρησιμοποιώντας την παγκόσμια ικανότητα built-queueing μας. Οι επηρεαζόμενες κατασκευές γνώρισαν μια απροσδόκητη παύση έως και 8 λεπτών περίπου στο "αναμονή για την υποδομή" στάδιο πριν από τη συνέχιση, αντί να προχωρήσει εντός της αναμενόμενης υποδεύτερης φοράς. Η συνολική δόμηση της βραδύτητας ήταν διαλείπουσα. # Σύγκρουση * Όλες οι κατασκευές CI ήταν δυνητικά υπόκεινται σε καθυστέρηση; αντίκτυπος ήταν πιο έντονη για τις κατασκευές σε Harness Cloud-φιλοξενούμενη υποδομή χρησιμοποιώντας το παγκόσμιο χαρακτηριστικό κατασκευής-queueing. * Επηρεαζόμενα κτίρια βίωσε μια ανεξήγητη παύση μέχρι περίπου 8 λεπτά πριν συνεχιστούν, ακολουθούμενη από μια πιο αργή " ψυχρή εκκίνηση - δεδομένου ότι μια προ-επιφύλαξη υπολογιστική υποδοχή δεν ήταν διαθέσιμη - αυτό παρουσιάστηκε στους χρήστες ως αργή builds αντί να οικοδομήσουμε αποτυχίες. * Οι λογαριασμοί που εκτελούνται σε νεότερες εκδόσεις ανάθεση \(858xx και πάνω\) δεν επηρεάστηκαν. * Κανένα οικοδόμημα δεν απέτυχε οριστικά ως άμεσο αποτέλεσμα αυτού του ζητήματος, και δεν χάθηκαν δεδομένα. # Αιτία ρίζας Η βασική αιτία ήταν μια εσωτερική αλλαγή κώδικα που άθελά του έσπασε το πώς ένα συγκεκριμένο build-queueing εγγραφή διαβάστηκε πίσω από τη βάση δεδομένων μας κάποτε κατασκευές που είχαν ήδη τεθεί σε αναμονή κάτω από την προηγούμενη έκδοση του κώδικα συνάντησε τη νέα έκδοση. Επιλύσαμε τον άμεσο αντίκτυπο καθαρίζοντας τα επηρεαζόμενα αρχεία και επαναφέροντας την υποκείμενη αλλαγή κώδικα, και εφαρμόζουμε αρκετές διασφαλίσεις για να αποτρέψουμε την επανάληψη αυτής της κατηγορίας ζητημάτων. # Επόμενα βήματα Εκτιμούμε τον κίνδυνο μιας παρόμοιας επανάληψης τόσο χαμηλής όσο και οι ακόλουθες ενέργειες που λαμβάνονται υπόψη. Η συγκεκριμένη πορεία κώδικα που προκάλεσε αυτό το περιστατικό έχει ήδη επανέλθει, και εφαρμόζουμε διαρθρωτικές διασφαλίσεις, έτσι ώστε αυτή η γενική κατηγορία θεμάτων να μην μπορεί να επαναληφθεί, ανεξάρτητα από το πού στη βάση κώδικα θα μπορούσε να συμβεί διαφορετικά.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.
Αυτή τη στιγμή ερευνούμε αυτό το ζήτημα.
Το θέμα έχει εντοπιστεί και υλοποιείται μια λύση.
Εφαρμόστηκε μια ρύθμιση και παρακολουθούμε τα αποτελέσματα.
Συνεχίζουμε να παρακολουθούμε για τυχόν περαιτέρω ζητήματα.
Το περιστατικό λύθηκε.
# Περίληψη Μεταξύ 19 Ιουνίου και 17 Ιουλίου 2026, το ενσωματωμένο βήμα Git Clone — και κάθε βήμα του αγωγού χρησιμοποιώντας το πρόσθετο κλώνου drone-git — απέτυχε στο ARM64 Kubernetes οικοδομήσουμε την υποδομή με το σφάλμα exec /usr/local/bin/clone: exec σφάλμα μορφή. AMD64 \(Intel/AMD\) χτίζει, τα Windows χτίζει, και η VM δυαδική διαδρομή χωρίς δοχείο δεν επηρεάστηκαν. Η βασική αιτία ήταν ένα ελάττωμα στην εσωτερική διαδικασία έκδοσης εικόνας μας που προκάλεσε ARM64-tagged drone-git εικόνες να περιέχουν πραγματικά AMD64 δυαδικά. Αναγνωρίσαμε και μετριάσαμε το θέμα την ίδια μέρα που αναφέρθηκε επαναφέροντας την εικόνα drone-git στην τελευταία γνωστή-καλή έκδοση. Δεν απαιτείται καμία ενέργεια ή αλλαγή ρύθμισης του πελάτη. # Αιτία ρίζας Στις 19 Ιουνίου 2026, μια αποκατάσταση ασφαλείας αναδιάρθρωσε τον τρόπο κατασκευής της εικόνας drone-git. Οι κατασκευές AMD64 ενημερώθηκαν σωστά, αλλά ο αγωγός κατασκευής ARM64 δεν κατασκεύασε άμεσα αρχεία ARM64 — προσάρμοσε το αρχείο κατασκευής AMD64 μέσω αντικατάστασης κειμένου και το συνέταξε σε υποδομές ARM64. Η αλλαγή της 19ης Ιουνίου άλλαξε το αρχείο AMD64 έτσι ώστε η αντικατάσταση σιωπηρά no-op'd αντί να αποτύχει, έτσι ο αγωγός δημοσίευσε μια εικόνα με ετικέτα ARM64 του οποίου τα διάρια Git Clone και Git LFS είχαν ακόμα συνταχθεί για AMD64. # Σύγκρουση * Επηρεασμένο: Το ενσωματωμένο βήμα Git Clone, και κάθε βήμα του αγωγού χρησιμοποιώντας το πρόσθετο κλώνων drone-git, που εκτελείται σε ARM64 Kubernetes κατασκευή υποδομών, σε όλους τους λογαριασμούς, μεταξύ 6 και 17 Ιουλίου 2026. * Σύμπτωμα: Οι κατασκευές απέτυχαν στο βήμα Git Clone με exec /usr/local/bin/clone: exec format error. * Δεν επηρεάζεται: AMD64 \ (Intel/AMD\) Kubernetes και VM κατασκευές, Windows κατασκευάζει, η VM διαδρομή εκτέλεσης χωρίς εμπορευματοκιβώτιο, και σκληρυμένη παραλλαγή εικόνας μας. # Μετριασμός Επιστρέψαμε την έκδοση drone-git εικόνας που χρησιμοποιήθηκε σε όλες τις επηρεαζόμενες υπηρεσίες στην τελευταία γνωστή-καλή κυκλοφορία. Αυτό επέλυσε πλήρως τις αστοχίες εκτέλεσης του ARM64· δεν απαιτούνταν αλλαγές στη διαμόρφωση του πελάτη. # Επόμενα βήματα Για να αποτραπεί η επανάληψη τέτοιων ζητημάτων. * Ξαναχτίστε τον αγωγό ARM64 έκδοση εικόνας για να οικοδομήσουμε τα αφιερωμένα αρχεία ARM64 μας οικοδομήσουμε άμεσα, αντί να προσαρμόσετε τα αρχεία κατασκευής AMD64. * Ενισχύστε την αυτοματοποιημένη μεταδημοσίευση επικύρωσης σε κάθε έκδοση της εικόνας: επαληθεύστε ότι η δυαδική αρχιτεκτονική ταιριάζει με την ετικέτα της εικόνας, και εκτελέστε μια λειτουργική δοκιμή καπνού πριν από μια εικόνα θεωρείται εκρηκτική. * Επέκταση αυτοματοποιημένη κάλυψη δοκιμών για να συμπεριλάβει ARM64 Kubernetes οικοδομήσουν σενάρια. * Αφαιρέστε τις επηρεαζόμενες ενδιάμεσες εκδόσεις εικόνων από την κυκλοφορία μόλις επικυρωθεί η διορθωμένη κυκλοφορία.
Αυτόματη μετάφραση από την επίσημη ενημέρωση του συμβάντος.