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

1. 22 Οκτωβρίου 2026 στις 4:06 μ.μ. UTCidentified

   Έχουμε εντοπίσει ένα θέμα όπου τα email για SLO, Triggers, και Ανίχνευση Ανωμαλιών δεν στέλνουν. Προσπαθούμε να το διορθώσουμε.

2. 22 Οκτωβρίου 2026 στις 5:07 μ.μ. UTCresolved

   Μεταξύ 03:53 PM UTC έως 4:08 PM UTC είδαμε τις αποτυχίες αποστολής ηλεκτρονικού ταχυδρομείου στην οποία ένας μικρός αριθμός των πελατών (10 επιχείρηση, 8 αυτο-serve, και 1 pro σχέδιο) είχαν αντίκτυπο. Αυτό ήρθε σε 508 emails συνολικά, ή ~1% της καθημερινής αποστολής email μας. Προσπαθούμε να διασφαλίσουμε ότι αυτή η κατάσταση αποτυχίας δεν θα μπορέσει να ξανασυμβεί.

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

1. 20 Οκτωβρίου 2026 στις 2:04 μ.μ. UTCinvestigating

   Αυτή τη στιγμή ερευνούμε την υποβάθμιση των διαφόρων υπηρεσιών στην περιοχή των ΗΠΑ.

2. 20 Οκτωβρίου 2026 στις 3:18 μ.μ. UTCinvestigating

   Αναγνωρίσαμε και απομονώσαμε την αντικρουόμενη υπηρεσία και βλέπουμε ανάκαμψη στην εκτέλεση ερωτημάτων. Η επεξεργασία SLO παραμένει υποβαθμισμένη.

3. 20 Οκτωβρίου 2026 στις 4:26 μ.μ. UTCresolved

   Η επεξεργασία SLO έχει ανακάμψει πλήρως. Όλες οι υπηρεσίες είναι πλέον λειτουργικές.

4. 21 Οκτωβρίου 2026 στις 11:26 μ.μ. UTCpostmortem

   Στις 20 Οκτωβρίου, βιώσαμε περίπου τρεις ώρες υποβαθμισμένης υπηρεσίας στην περιοχή των ΗΠΑ. * Από τις 13:30 έως τις 14:40 UTC, ερωτώντας, η Honeycomb UI, η διαχείριση API, και ενεργοποιεί την εμπειρία αυξημένη λανθάνουσα λανθάνουσα και τα ποσοστά σφαλμάτων, με την υψηλότερη επίπτωση μεταξύ 13:55 και 14:10 UTC. Κατά τη διάρκεια αυτού του διαστήματος, οι πελάτες μπορεί να έχουν βιώσει αργά ή αποτυχημένα ερωτήματα και μια οκνηρή UI, και μερικές ειδοποιήσεις ενεργοποίησης μπορεί να έχουν καθυστερήσει ή να έχουν χάσει. * Από τις 13:26 έως περίπου 16:10 UTC, η επεξεργασία SLO καθυστέρησε, οπότε τα δεδομένα SLO μπορεί να έχουν εμφανιστεί ξεπερασμένα και οι ειδοποιήσεις για εγκαύματα μπορεί να έχουν καθυστερήσει ή να έχουν χαθεί κατά τη διάρκεια αυτού του χρόνου. * Από 13:57 έως 14:09 UTC, περίπου οι μισές αιτήσεις για το συμβάν κατάποσης API έλαβαν 5xx σφάλματα, με μικρότερη επίπτωση μεταξύ 13:48 και 13:55 UTC \(1% ποσοστό σφάλματος\) και για περίπου ένα λεπτό στις 14:15 UTC \(1,9% ποσοστό σφάλματος\). Η τηλεμετρία που απορρίφθηκε κατά τη διάρκεια αυτών των περιόδων δεν απορροφήθηκε εκτός αν ο αποστολέας την ξαναδοκίμασε επιτυχώς. Οι πελάτες μπορούν να δουν κενά στα δεδομένα τους για αυτές τις περιόδους, συμπεριλαμβανομένων των ενεργοποιήσεων και των SLO που το καλύπτουν. Οι εφημερεύοντες μηχανικοί μας πρωτοεφημερεύθηκαν στις 13:43 UTC από μια ειδοποίηση σχετικά με ενεργοποιήσεις που δεν λειτουργούν στην ώρα τους, και ανακαλύψαμε την εσωτερική μας αντίδραση ως περαιτέρω ειδοποιήσεις που ακολούθησαν. Η έρευνά μας έδειξε ότι η κεντρική βάση δεδομένων ήταν κορεσμένη από ένα μεγάλο αριθμό μακροχρόνιων αναγνώσιμων ερωτήσεων. Κάναμε μια αποτυχία στη βάση δεδομένων για να μειώσουμε το φορτίο. Αυτό μείωσε εν συντομία την πίεση, αλλά τα ίδια ερωτήματα επανεμφανίστηκαν σύντομα στη νέα πρωτογενή, οπότε δεν επιλύθηκε το πρόβλημα. Στη συνέχεια, μειώσαμε το φορτίο της βάσης δεδομένων τερματίζοντας αυτά τα ερωτήματα και σταματώντας προσωρινά την επεξεργασία SLO, η οποία αποκατέστησε τις άλλες επηρεαζόμενες υπηρεσίες. Μόλις τέθηκε σε εφαρμογή ένα χρονικό όριο από την πλευρά της βάσης δεδομένων σχετικά με το υπεύθυνο ερώτημα, επαναλάβαμε την επεξεργασία SLO, η οποία στη συνέχεια προηγήθηκε, και επισκευάσαμε ιστορικά δεδομένα SLO. Αυτά τα ερωτήματα προήλθαν από έναν έλεγχο SLO επεξεργασία μας τρέχει κάθε φορά που ένα περιβάλλον Honeycomb αλλαγή ρυθμίσεων. Σε μια συντριπτική πλειοψηφία των περιπτώσεων, ολοκληρώνεται σε λίγα χιλιοστά του δευτερολέπτου. Για το 0,1% των περιβαλλόντων μας με ασυνήθιστα μεγάλο αριθμό SLO και υπολογισμένα πεδία, ωστόσο, η βάση δεδομένων το έτρεξε με πολύ αναποτελεσματικό τρόπο, και μια ενημέρωση ρουτίνας σε ένα τέτοιο περιβάλλον ρυθμίσεων έκανε τον έλεγχο πολύ αργό για να ολοκληρωθεί ποτέ. Τα ερωτήματα αυτά συνεχίστηκαν αφού η αιτούσα υπηρεσία χρονομέτρησε, και επανειλημμένες προσπάθειες αύξησαν το φορτίο σε μια βάση δεδομένων που μοιραζόταν με διάφορες υπηρεσίες. Για να μην ξανασυμβεί αυτό, εκτός από το χρονικό όριο της βάσης δεδομένων, αλλάξαμε τον τρόπο με τον οποίο η βάση δεδομένων εκτελεί το ερώτημα για περιβάλλοντα όπως αυτό, το οποίο κατέβασε το χρόνο λειτουργίας της από λεπτά σε μερικά χιλιοστά του δευτερολέπτου. Προσαρμόσαμε επίσης τα όρια συναγερμού μας για να διασφαλίσουμε ότι ένας μηχανικός εφημερίας ενημερώνεται για τις μελλοντικές αλλαγές στο φορτίο της βάσης δεδομένων γρήγορα.

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

1. 20 Οκτωβρίου 2026 στις 5:07 μ.μ. UTCresolved

   Από τις 13:57 έως τις 14:09 UTC , γεγονός που καταναλώνεται στο περιβάλλον παραγωγής των ΗΠΑ Honeycomb υποβαθμίστηκε από ένα παράλληλο περιστατικό . Κατά τη διάρκεια αυτού του παραθύρου, περίπου το 53% των εισερχόμενων γεγονότων έλαβε 5xx σφάλματα.

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

1. 21 Αυγούστου 2026 στις 3:21 μ.μ. UTCidentified

   Το Canvas δεν φορτώνει για τους πελάτες στις περιοχές των \"ΠΑ και της ΕΕ και έχουμε εντοπίσει ποια πιστεύουμε ότι είναι η αιτία και εξελίσσουμε μια λύση.

2. 21 Αυγούστου 2026 στις 3:25 μ.μ. UTCmonitoring

   Έχουμε αναπτύξει τη διόρθωση και βλέπουμε την αποκατάσταση της φυσιολογικής λειτουργικότητας Κάνβας.

3. 21 Αυγούστου 2026 στις 3:59 μ.μ. UTCresolved

   Το περιστατικό λύθηκε.

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

1. 10 Αυγούστου 2026 στις 1:01 μ.μ. UTCmonitoring

   Από τις 11:36UTC έως τις 12:43UTC, ερωτήματα στις ΗΠΑ1 που διαβάζουν παλαιότερα δεδομένα επέστρεψαν λάθη ή time out. Ερωτήματα σχετικά με τα πρόσφατα δεδομένα δεν επηρεάστηκαν, και καμία τηλεμετρία δεν χάνεται. Το ζήτημα έχει εντοπιστεί, και υπάρχει μια λύση. Επί του παρόντος παρακολουθούμε την κατάσταση για να επιβεβαιώσουμε την επίλυση.

2. 10 Αυγούστου 2026 στις 8:35 μ.μ. UTCresolved

   Η λύση είναι έτοιμη και επιβεβαιώσαμε την ανάλυση. Ερωτήματα και SLOs επεξεργάζονται κανονικά.

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

1. 31 Ιουλίου 2026 στις 3:42 μ.μ. UTCresolved

   Μεταξύ 10:30 και 11:00 AM EDT, βιώσαμε αυξημένες αποτυχίες και βραδύτητα. Ο αντίκτυπος έχει υποχωρήσει και επί του παρόντος ερευνούμε και παρακολουθούμε την κατάσταση.

2. 21 Αυγούστου 2026 στις 1:18 μ.μ. UTCpostmortem

   Ξεκινώντας από τις 9:50 π.μ. Κεντρική Ώρα στις 31 Ιουλίου λάβαμε ειδοποιήσεις σχετικά με το ερώτημα για την υγεία και τη λανθάνουσα κατάσταση. Η αιτία τελικά εντοπίστηκε σε μια σύγκρουση δύο διαφορετικών παραγόντων. Πρώτον, εισάγουμε το Lambda Managed Institutions \(LMI\) στην αρχιτεκτονική ερωτημάτων μας, τα οποία συμπεριφέρονται παρόμοια με τα κλασικά λάμδα με πολλούς τρόπους και είχαν εισαχθεί ως μέρος της εργασίας γύρω από την ερώτηση βελτιώσεις απόδοσης με στόχο μια καλύτερη και ταχύτερη εμπειρία χρήστη. Δυστυχώς, μια διαφορά μεταξύ κλασικών λάμδα και LMI που ανακαλύψαμε είναι η 15λεπτη σκληρή στάση των κλασικών λάμδα δεν υπάρχει σε LMIs, πράγμα που σημαίνει ότι ορισμένες υποθέσεις που ενσωματώνονται στο σύστημα ερωτήσεών μας δεν κρατούνται πλέον. Κατά τη στιγμή του συμβάντος, το νεότερο χαρακτηριστικό μας Canvas ήταν τρέχει παρτίδες των ερωτημάτων για έναν πελάτη που θα πρέπει να έχουν έναν εαυτό επιβάλλεται ένα λεπτό έξω. Αυτό το τάιμ άουτ δεν κοινοποιήθηκε σωστά στο λάμδα, και ενώ με τα κλασικά λάμδα το έργο θα έκοβε αυτόματα στα 15 λεπτά, τα νέα LMI δεν εφάρμοζαν αυτό το είδος του μηχανισμού ασφάλειας. Ως αποτέλεσμα, κάποια μεγάλα ερωτήματα έτρεχαν για έως και 30 λεπτά, οδηγώντας μέχρι λανθάνουσα λανθάνουσα query σε όλο το ταμπλό και με αποτέλεσμα σφάλματα για τους χρήστες που προσπαθούσαν να εκτελέσουν νέα ερωτήματα. Το σύστημα ανακτήθηκε μέχρι τις 10:10 AM CT, 20 λεπτά αργότερα, όταν τα μεγάλα ερωτήματα εκκαθαρίστηκαν, αλλά συνεχίσαμε να ερευνούμε την αιτία του συμβάντος. Μόλις προσδιορίσαμε αυτή την αδυναμία στην απορία μας στην αρχιτεκτονική αρχίσαμε να εργαζόμαστε για να την διορθώσουμε και να αποτρέψουμε το ίδιο περιστατικό να συμβεί ξανά. Έχουμε στείλει όλα τα σχετικά περιστατικά παρακολούθησης.

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

1. 27 Ιουλίου 2026 στις 1:13 μ.μ. UTCinvestigating

   Βλέπουμε να προκαλούν διαλείπουσα αποτυχία στην περιοχή της ΕΕ. Ερευνούμε ενεργά τον σκοπό.

2. 27 Ιουλίου 2026 στις 1:52 μ.μ. UTCinvestigating

   Συνεχίζουμε να βλέπουμε θέματα με τα ερεθίσματα και παρατηρούμε επίσης ζητήματα με τα ερωτήματα. Ερευνούμε για την αιτία και των δύο.

3. 27 Ιουλίου 2026 στις 4:01 μ.μ. UTCmonitoring

   Αναγνωρίσαμε την πηγή του ζητήματος, εφαρμόσαμε μια προσωρινή λύση και εργαζόμαστε σε μια μόνιμη λύση. Συνεχίζουμε να παρακολουθούμε την κατάσταση.

4. 27 Ιουλίου 2026 στις 7:46 μ.μ. UTCmonitoring

   Βλέπουμε μια παλινδρόμηση στην απόδοση με μερική υποβάθμιση και των δύο ενεργοποιήσεων και ερωτημάτων. Δουλεύουμε για να επανέλθουμε.

5. 27 Ιουλίου 2026 στις 10:51 μ.μ. UTCmonitoring

   Η μερική υποβάθμιση έχει επιλυθεί για όλους τους πελάτες εκτός από εκείνους που έχουν επικοινωνήσει ειδικά. Εργαζόμαστε πάνω σε μέτρα μετριασμού, έτσι ώστε να μπορέσουμε να αποκαταστήσουμε πλήρως τη λειτουργία ενεργοποίησης για όλους.

6. 28 Ιουλίου 2026 στις 6:21 μ.μ. UTCmonitoring

   Συνεχίζουμε να παρακολουθούμε για τυχόν περαιτέρω ζητήματα.

7. 28 Ιουλίου 2026 στις 6:30 μ.μ. UTCresolved

   Η υποβάθμιση των ερωτημάτων και των ενεργοποιήσεων έχει επιλυθεί και είμαστε πίσω στην πλήρη λειτουργικότητα.

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

1. 2 Ιουλίου 2026 στις 6:10 μ.μ. UTCinvestigating

   We are currently investigating this issue.

2. 2 Ιουλίου 2026 στις 6:13 μ.μ. UTCmonitoring

   Clearing the CDN cache appears to have solved the issue.

3. 3 Ιουλίου 2026 στις 12:31 π.μ. UTCresolved

   This incident has been resolved.

1. 29 Ιουνίου 2026 στις 10:07 μ.μ. UTCmonitoring

   Starting at 14:24 PT, there was an issue with the Activity Log causing events to stop being processed. You may notice a gap starting at that time. We are slowly backfilling these events and do not expect any data loss to occur. We expect the full data log to be restored around 17:30 PT.

2. 30 Ιουνίου 2026 στις 12:47 π.μ. UTCresolved

   Backfill of the Activity Log events has completed. All events during the affected period should be present.

1. 25 Ιουνίου 2026 στις 6:10 μ.μ. UTCinvestigating

   We are investigating an issue with delayed ingest in the EU region. SLOs and Trigger evaluations may also be delayed.

2. 25 Ιουνίου 2026 στις 6:31 μ.μ. UTCmonitoring

   We are monitoring the situation. Events may have been delayed between 17:53 and 18:04 UTC.

3. 25 Ιουνίου 2026 στις 8:41 μ.μ. UTCresolved

   This incident has been resolved.

1. 24 Ιουνίου 2026 στις 6:14 μ.μ. UTCinvestigating

   We are investigating an issue with delayed ingest in the US and EU region. Our engineers are rolling back a recent deploy. SLOs and Trigger evaluations may also be delayed.

2. 24 Ιουνίου 2026 στις 6:22 μ.μ. UTCmonitoring

   We have rolled back the deploy and ingest service has recovered. There has been an ingest outage from 17:55 - 18:14 UTC. We have also observed an delay for Service Maps.

3. 24 Ιουνίου 2026 στις 6:31 μ.μ. UTCmonitoring

   Triggers, SLOs and Service Maps are recovered. We are continuing to monitoring the Ingest Service

4. 24 Ιουνίου 2026 στις 7:04 μ.μ. UTCresolved

   All services have been fully recovered. Impact window: 17:55–18:17 UTC Regions affected: Primary impact in US. The EU region was affected to a much lesser degree. During this period, the following effects may have occurred: Ingest: Some data was not ingested, resulting in complete or partial data loss for events sent during the window. Triggers: Triggers may have failed to fire within the impact window. SLOs: SLI values across the affected window are skewed by the missing data and may show artificial dips or accelerated budget burn. Service Maps: Maps covering the outage window are incomplete. Services and dependencies may be under-counted, as their traces were not ingested. We apologize for the disruption. Please reach out if you have any questions about how this may have affected your data.

5. 2 Ιουλίου 2026 στις 8:10 μ.μ. UTCpostmortem

   On June 24, we experienced approximately 30 minutes of severe data ingestion degradation in Honeycomb’s US and EU instances. During this degradation, Honeycomb rejected a significant percentage of inbound telemetry, and customers would have seen up to a half-hour gap in ingested telemetry. Additionally, during this same time window, customers would have experienced data processing degradation and service disruption within Anomaly Detection and Service Maps. A deployment containing a change to how services retrieve dataset schemas into local caches caused a cascading set of failures, resulting in failed remote cache retrievals, and subsequently, a MySQL stampede due to several services falling back to retrieving schemas from the database. This stampede resulted in significant memory utilization growth, causing some services to crash loop with out-of-memory exceptions while retrieving schemas. Customers would have seen 5xx errors from our ingestion APIs when this occurred, because ingestion services were among those that were crash looping. This also included crash looping from services responsible for Anomaly Detection and Service Maps. Right after these service crash loops began, alerts fired for the crashing services, and procedures were run to pin all services back to the last known good build before the breaking change landed. Once services were running the previous deploy’s build, the 5xx error responses from ingestion APIs returned to nominal baseline levels, and services that were crash looping recovered and resumed normal operation. The underlying issue centered on how dataset schema cache payloads and metadata were serialized to memcached for remote cache retrieval, and how memcached clients deserialize that data before writing it to a local cache. The code change contained a feature flag to toggle the serialization behavior, and backwards-compatibility safeguards for clients deserializing different schema versions from memcached. However, services’ schema deserialization prior to the feature flag flip on did not behave as intended, treating each backwards-compatible schema read as a hard error rather than as a fallback, which subsequently caused every remote schema cache read to fall through to the database. Subsequent analysis and review of the code identified the issue and we have re-deployed this change with a fix along with additional tests. Services now correctly and successfully deserialize schemas from memcached in a safe, backwards-compatible manner.

1. 19 Ιουνίου 2026 στις 4:39 μ.μ. UTCinvestigating

   We are aware of an issue affecting Honeycomb MCP. Write tool functionality may be degraded. Read tools are unaffected.

2. 19 Ιουνίου 2026 στις 5:18 μ.μ. UTCmonitoring

   We are aware of an issue affecting Honeycomb MCP. Write tool functionality may be degraded. Read tools are unaffected.

3. 19 Ιουνίου 2026 στις 5:21 μ.μ. UTCresolved

   MCP Write Tools have been restored. MCP users may need to reconnect to see all available tools.

1. 18 Ιουνίου 2026 στις 7:10 μ.μ. UTCresolved

   Beginning June 17th, enhance-related requests were failing to complete. We've since identified and deployed a fix, and enhance is now fully operational. Thank you for your patience.

1. 17 Ιουνίου 2026 στις 2:01 μ.μ. UTCinvestigating

   We are continuing to investigate intermittent slowness and query failures affecting our Production EU Region. We will provide an update as soon as we have more information.

2. 17 Ιουνίου 2026 στις 3:29 μ.μ. UTCmonitoring

   Querying in our Production EU Region is fully operational. We will continue to monitor for any abnormal behavior.

3. 17 Ιουνίου 2026 στις 9:14 μ.μ. UTCresolved

   We have identified the root cause of the intermittent slowness and query failures affecting our Production EU Region. The issue was triggered by a large volume of dataset deletions that caused elevated database load, resulting in query instability. No data was lost during this incident. Service has been restored. A fix has been applied to help prevent recurrence.

1. 17 Ιουνίου 2026 στις 12:01 μ.μ. UTCinvestigating

   We are currently investigating the cause of slowness and query failures in our Production EU Region.

2. 17 Ιουνίου 2026 στις 12:32 μ.μ. UTCresolved

   The issue is now resolved and querying is back to fully functional.

1. 11 Ιουνίου 2026 στις 11:17 μ.μ. UTCresolved

   Requests to Honeycomb's Query Data and Management APIs in the production-eu1 environment encountered increased error rates between approximately 15:35 and 22:24 UTC. Event ingestion was not affected. The issue has been resolved.

1. 10 Ιουνίου 2026 στις 8:58 μ.μ. UTCinvestigating

   We are investigating an issue with delayed ingest in the EU region. Received events are still being stored, but there may be a delay in event retrieval in queries. SLOs and Trigger evaluations may also be delayed.

2. 10 Ιουνίου 2026 στις 9:28 μ.μ. UTCinvestigating

   Queries should no longer be delayed. SLOs and Trigger evaluations remain impacted.

3. 10 Ιουνίου 2026 στις 9:29 μ.μ. UTCidentified

   The issue has been identified and a fix is being implemented.

4. 10 Ιουνίου 2026 στις 10:02 μ.μ. UTCresolved

   All services are now healthy.

1. 8 Ιουνίου 2026 στις 4:37 μ.μ. UTCinvestigating

   We are currently investigating this issue.

2. 8 Ιουνίου 2026 στις 5:41 μ.μ. UTCresolved

   This incident has been resolved.

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

   Canvas agent cannot load honeycomb internal tools.

2. 3 Ιουνίου 2026 στις 8:51 μ.μ. UTCresolved

   This incident has been resolved.

1. 21 Μαΐου 2026 στις 11:22 μ.μ. UTCinvestigating

   We have identified and are working to resolve an issue that is causing query results to return inconsistent results.

2. 22 Μαΐου 2026 στις 12:49 π.μ. UTCinvestigating

   Impact from this issue has concluded. For a period of time (different between US and EU instances, noted below), queries spanning data older than the most recent 2 hours with certain GROUP / WHERE clauses returned inconsistent results. Data was never lost, and reruns of the same queries will show the previously missing data. US impact times: 21:50 UTC - 23:20 UTC EU impact times: 20:50 UTC - 23:20 UTC

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

   This is an administrative update, marking the incident as Resolved. There has been no further impact since 23:20UTC on May 21 2026.