Istoricul incidentelor Treasure Data

1. 22 octombrie 2026 la 03:24 UTCidentified

   Din 13 octombrie 2026 02:00 UTC, unele locuri de muncă de import care citesc fișiere Parquet de la Amazon S3 complet cu succes, dar data de încărcare și coloane de timp ca text (șir) în loc de numere (lung). Dacă tabelul de destinație definește deja aceste coloane atâta timp, valorile importate sunt goale (NULL). Sunt afectate numai coloanele stocate cu data sau ora în fișierul Parquet. Alte coloane și alți conectori de date nu sunt afectați. Am identificat cauza, o schimbare introdusă în lansarea din 13 octombrie şi pregătim o doză. Noi evaluăm întreaga sferă a impactului. Vom oferi o actualizare în 30 de minute.

2. 22 octombrie 2026 la 04:06 UTCidentified

   Am identificat cauza de Amazon S3 Parquet importă data de încărcare și coloane de timp ca text (șir) în loc de numere (lung) din 13 octombrie 2026 02:00 UTC, și sunt de punere în aplicare a unui fix. Până la implementarea fixării, locurile de muncă de import afectate continuă să se completeze cu succes cu aceste coloane încărcate ca text. Alte coloane și alți conectori de date nu sunt afectați. Verificam integritatea datelor pentru datele importate in aceasta perioada. Vă vom oferi o actualizare într-o oră.

3. 22 octombrie 2026 la 06:22 UTCidentified

   Am identificat cauza de Amazon S3 Parquet importă data de încărcare și coloane de timp ca text (șir) în loc de numere (lung) din 13 octombrie 2026 02:00 UTC, și sunt punerea în aplicare a unui fix. Până la implementarea fix, locurile de muncă de import afectate continuă să se completeze cu aceste coloane încărcate ca text. Alte coloane și alți conectori de date nu sunt afectați. Verificam integritatea datelor pentru datele importate in aceasta perioada. Vom oferi o actualizare în 30 de minute.

4. 22 octombrie 2026 la 07:44 UTCmonitoring

   Am trimis un fix pentru Amazon S3 Parquet importă data de încărcare și coloane de timp ca text. Noi locuri de muncă de import încarcă aceste coloane ca numere (lunge), ca înainte de 13 octombrie 2026. Monitorizăm pentru a asigura stabilitatea. Vom oferi o actualizare în 30 de minute.

5. 22 octombrie 2026 la 10:15 UTCresolved

   A se vedea nota de subsol 1. Un fix a fost pus în aplicare pe 22 octombrie 2026 la 07:40 UTC, iar noile locuri de muncă de import încarcă aceste coloane ca numere (lunge), ca înainte de 13 octombrie 2026. Datele importate între 13 octombrie 2026 02:00 UTC și 22 octombrie 2026 07:40 UTC pot conține coloane cu data și ora afectate. Vom contacta direct clienţii afectaţi. Ne cerem scuze pentru deranj şi vă mulţumim pentru răbdare.

Traducere automată din actualizarea oficială a incidentului.

1. 7 octombrie 2026 la 04:21 UTCidentified

   Deoarece aproximativ 22:55 UTC pe 6 octombrie, utilizatorii aplicației mobile Comoara AI Voice ar putea fi în imposibilitatea de a transfera noi înregistrări de pe dispozitivul lor. Transferul eşuează cu o eroare "neautorizată." Acest lucru afectează atât transferurile Wi-Fi cât și cele Bluetooth. Am identificat cauza și sunt implementarea unui fix. Înregistrările care au fost deja transferate şi transcrierile şi rezumatele lor nu sunt afectate. Vom oferi o actualizare în 30 de minute.

2. 7 octombrie 2026 la 04:27 UTCidentified

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

3. 7 octombrie 2026 la 04:54 UTCmonitoring

   Am implementat un server-side fix pentru eșecurile de transfer de înregistrare în Treasure AI Voice. Noile transferuri de pe aplicația mobilă reușesc din nou. Nu este necesară nicio actualizare a aplicației. Înregistrările care nu au reuşit să se transfere în timpul incidentului pot fi transferate din nou de pe dispozitiv. Monitorizăm pentru a asigura stabilitatea.

4. 7 octombrie 2026 la 05:24 UTCresolved

   Eşecurile transferului de înregistrare din Comoara Al Voice au fost rezolvate. Toate sistemele funcţionează normal. Între aproximativ 22:55 UTC la 6 octombrie și [timpul fix] UTC la 7 octombrie, noi înregistrări nu au putut fi transferate din aplicația mobilă. Am implementat un server-side fix, și nu este necesară actualizarea aplicației. Înregistrările care nu au fost transferate în această perioadă pot fi transferate din nou de pe dispozitiv. Mulţumesc pentru răbdare.

Traducere automată din actualizarea oficială a incidentului.

1. 30 septembrie 2026 la 04:36 UTCresolved

   Între 28 septembrie (5:30 PM UTC) și 29 septembrie (6:30 PM UTC) clienții fără segmente de lot care au programat actualizări atribute ar fi văzut locuri de muncă eșuate care împiedică încărcarea datelor pe loturi în Reactor. Clienții ar fi văzut erori în timp ce așteptau modificările de configurare pentru actualizare. Impactul este orice aplicații în timp real, personalizări, sau campanii în timpul acelei ferestre s-ar putea să se fi bazat pe date vechi atribut lot. Sistemul a recuperat și fluxurile de lucru trimit acum date actualizate.

Traducere automată din actualizarea oficială a incidentului.

1. 29 septembrie 2026 la 17:22 UTCinvestigating

   Investigăm în prezent locuri de muncă de export pe loturi care nu au încărcat date în regiunea Reactor din SUA (AWS). Actualizările datelor vor fi amânate până la 24 de ore. Vom actualiza starea într-o oră.

2. 29 septembrie 2026 la 18:20 UTCmonitoring

   S-a pus în aplicare un fix și am observat că locurile de muncă au succes.

3. 29 septembrie 2026 la 21:18 UTCresolved

   Acest incident a fost rezolvat, iar echipa noastră de suport va urmări clienţii afectaţi.

Traducere automată din actualizarea oficială a incidentului.

1. 28 septembrie 2026 la 03:41 UTCinvestigating

   Avem în prezent o problemă cu caracteristica noastră Live Chat pentru planurile de sprijin Corporate and Enterprise. Echipa noastră investighează activ. Puteți ajunge încă echipa noastră de sprijin ca de obicei prin e-mailing [email protected]. Apreciem răbdarea şi ne cerem scuze pentru orice neplăceri.

2. 28 septembrie 2026 la 13:16 UTCresolved

   Am identificat și rezolvat problema care afectează caracteristica Live Chat pentru planurile de sprijin Corporate and Enterprise. Serviciul a fost restaurat complet şi funcţionează normal. Ne cerem sincer scuze pentru orice inconvenient pe care l-am cauzat şi vă mulţumim pentru răbdare.

Traducere automată din actualizarea oficială a incidentului.

1. 17 septembrie 2026 la 03:14 UTCidentified

   Am identificat cauza întârzierilor care afectează e-mailurile tranzacţionale din interfaţa noastră web şi lucrăm la o soluţie. Clienții pot primi unele e-mailuri mai târziu decât se aștepta în acest timp. Emailurile afectate includ notificări de sistem și cereri de resetare a parolei. Alte servicii de e-mail funcționează în mod normal. Vom furniza o altă actualizare în 30 de minute.

2. 17 septembrie 2026 la 03:44 UTCmonitoring

   Transactional e-mail de livrare este de recuperare, dar ar putea dura ceva timp pentru a reveni la nivelurile normale. Continuăm să monitorizăm serviciul. Alte servicii de e-mail nu sunt afectate. Vom furniza o altă actualizare în 2 ore.

3. 17 septembrie 2026 la 06:10 UTCmonitoring

   Transactional e-mail de livrare este de recuperare, dar ar putea dura ceva timp pentru a reveni la nivelurile normale. Continuăm să monitorizăm serviciul. Alte servicii de e-mail nu sunt afectate. Vom furniza o altă actualizare în 24 de ore.

4. 18 septembrie 2026 la 06:51 UTCmonitoring

   Transactional e-mail de livrare este de recuperare, dar ar putea dura ceva timp pentru a reveni la nivelurile normale. Livrarea continuă să se îmbunătățească constant. Continuăm să monitorizăm serviciul. Alte servicii de e-mail nu sunt afectate. Vom furniza o altă actualizare în 7 zile.

5. 25 septembrie 2026 la 04:44 UTCmonitoring

   Transactional e-mail de livrare continuă să recupereze, dar ar putea dura ceva timp pentru a reveni la nivelurile normale. Livrarea rămâne stabilă şi continuăm să monitorizăm serviciul. Alte servicii de e-mail nu sunt afectate. Vom oferi o altă actualizare în termen de șapte zile, sau mai devreme în cazul în care condițiile se schimbă.

6. 5 octombrie 2026 la 02:19 UTCmonitoring

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

7. 5 octombrie 2026 la 02:20 UTCmonitoring

   Transactional e-mail de livrare continuă să recupereze, dar ar putea dura ceva timp pentru a reveni la nivelurile normale. Livrarea rămâne stabilă şi continuăm să monitorizăm serviciul. Alte servicii de e-mail nu sunt afectate. Vom oferi o altă actualizare în termen de 14 zile, sau mai devreme în cazul în care condițiile se schimbă.

8. 16 octombrie 2026 la 00:04 UTCresolved

   Nu mai observăm întârzieri de livrare. Am îmbunătățit monitorizarea și vom continua să urmărim întreruperile. Dacă observați orice livrare lentă, vă rugăm să contactați echipa noastră de sprijin pentru asistență.

Traducere automată din actualizarea oficială a incidentului.

1. 27 iulie 2026 la 08:29 UTCresolved

   Între 7/25 și astăzi, 7/27 la 11:30 AM JST, am experimentat o problemă de degradare a performanței care afectează BulkLoad (Conectorul de date Import), Exportul de Rezultat (Activarea) și Importul de vrac. În urma rapoartelor primite în această dimineață, echipa noastră de inginerie a investigat problema și a identificat sarcină mare de sistem în condiții specifice (în creștere întârziere în comunicarea componentelor interne) ca fiind cauza principală. Problema a fost rezolvată prin rotaţia completă a nodurilor serverului nostru, iar performanţa completă a fost restabilită la 11:30 AM JST. Ne cerem scuze sincer pentru orice neplăceri cauzate. În prezent, revizuim normele noastre de monitorizare și alertă pentru a preveni problemele similare în viitor.

Traducere automată din actualizarea oficială a incidentului.

1. 7 iulie 2026 la 17:04 UTCinvestigating

   Observăm performanţe degradate în Treasure Work şi TDX în regiunea Tokyo. Această problemă se limitează doar la modelul Claude Haiku 4.5 din regiunea Tokyo. Utilizatorii pot observa că cererile care utilizează Claude Haiku 4.5 erori de returnare sau pauză. În acest moment, nu vedem probleme cu alte modele. Ca un workaround, utilizatorii pot selecta un model diferit. Investigăm în mod activ această problemă și vom urmări să oferim o actualizare în 30 de minute.

2. 7 iulie 2026 la 17:40 UTCinvestigating

   Continuăm să investigăm această problemă și vom oferi o altă actualizare în 30 de minute.

3. 7 iulie 2026 la 18:07 UTCidentified

   Continuăm să explorăm această problemă și evaluăm în prezent o soluție potențială. Vom actualiza de îndată ce testarea noastră este completă.

4. 7 iulie 2026 la 19:42 UTCidentified

   Continuam sa lucram printr-o solutie potentiala si lucram pentru a identifica orice potential factor contributiv. Din nou, deoarece problema este localizată pe modelele Haiku 4.5 din regiunea Tokyo, recomandăm utilizatorilor să utilizeze temporar un model diferit dacă se confruntă cu rate ridicate de eroare. Ne cerem scuze pentru neplăceri şi vom avea în curând o noutate.

5. 7 iulie 2026 la 20:27 UTCmonitoring

   A fost implementată o soluţie şi monitorizăm rezultatele.

6. 7 iulie 2026 la 20:59 UTCresolved

   Această problemă a fost rezolvată. Treasure Work şi TDX funcţionează normal, iar modelul Claude Haiku 4.5 din regiunea Tokyo nu mai întâmpină erori sau temporizări. Mulţumesc pentru răbdare.

Traducere automată din actualizarea oficială a incidentului.

1. 26 iunie 2026 la 21:48 UTCidentified

   Experimentăm degradarea performanţelor Hive în regiunea SUA. Această ediţie a început pe 25 iunie 2026. Utilizatorii pot observa perioade mai lungi de executare a interogărilor decât se preconizează, în special pentru locurile de muncă pe termen lung cu volume mari de date. Am identificat cauza şi lucrăm la o soluţie. Vom oferi o actualizare în 30 de minute.

2. 26 iunie 2026 la 22:22 UTCidentified

   Experimentăm degradarea performanţelor Hive în regiunea SUA. Această ediţie a început pe 25 iunie 2026. Utilizatorii pot observa perioade mai lungi de executare a interogărilor decât se preconizează, în special pentru locurile de muncă pe termen lung cu volume mari de date. Am identificat cauza. Pentru a aborda această problemă, validăm o modificare a configurației clusterului înainte de a o aplica mediului de producție. Vom oferi o actualizare în 30 de minute.

3. 26 iunie 2026 la 22:57 UTCidentified

   Continuăm să lucrăm la un fix. Echipa noastra valideaza o schimbare a configuratiei clusterului inainte de a o aplica in mediul de productie. Vom oferi o actualizare în 30 de minute.

4. 26 iunie 2026 la 23:57 UTCmonitoring

   Am furnizat un nou grup cu capacitate suficientă și acum îi direcționăm locuri de muncă. Se așteaptă ca performanța de interogare să se recupereze treptat pe măsură ce grupul se stabilizează. Monitorizăm situaţia îndeaproape. Vă vom oferi o actualizare într-o oră.

5. 27 iunie 2026 la 01:13 UTCresolved

   Degradarea performanţelor din regiunea SUA a fost rezolvată. Am furnizat cu succes un nou grup şi am direcţionat tot traficul spre el. Sistemele funcţionează normal. Mulţumesc pentru răbdare.

Traducere automată din actualizarea oficială a incidentului.

1. 25 iunie 2026 la 11:46 UTCresolved

   Rezolvat În această perioadă, nodurile de calcul subiacente au fost instabile intermitent, ceea ce ar putea determina încetarea locurilor de muncă la export înainte de finalizarea acestora. În unele cazuri, un loc de muncă afectat s-ar putea fi încheiat fără un mesaj de eroare clar. Problema a fost rezolvată şi toate sistemele funcţionează normal. Integritatea datelor nu este influenţată de datele sursă din datele Comoara nu a fost afectată; numai livrarea locurilor de muncă la export către destinaţii externe în timpul acestei ferestre ar fi putut fi perturbată. Dacă ați rulat un rezultat / export de date în timpul acestei ferestre, vă recomandăm să-l confirmați completat și re-running-l în cazul în care ieșirea pare incomplet. De asemenea, vom contacta direct clienţii afectaţi. Mulţumesc pentru răbdare.

Traducere automată din actualizarea oficială a incidentului.

1. 24 iunie 2026 la 11:11 UTCresolved

   Am identificat o întârziere în înregistrarea de date de e-mail eveniment (cum ar fi deschis, clic, salt, evenimente de livrare, și evenimente de eroare) la mesele de eveniment client. Perioada afectată (aproximativ): - 22 iunie, 03:45 - 23 iunie 04:15 - 23 iunie, 07:00 - 24 iunie, 07:30 În aceste perioade, înregistrarea datelor de e-mail a fost amânată. E-mail de livrare în sine nu a fost afectat e-mailuri au fost trimise și primite în mod normal. Problema a fost rezolvată şi toate sistemele funcţionează normal. Evenimentele întârziate au fost complet prelucrate. Dacă ați rulat întrebări cu privire la mesele de eveniment sau eroare eveniment în perioadele afectate, vă sugerăm reluarea acestor întrebări pentru a obține rezultate exacte. Ne cerem scuze pentru neplăceri.

Traducere automată din actualizarea oficială a incidentului.

1. 5 mai 2026 la 16:20 UTCidentified

   Incident: Real-time Profile Deletion Workflow Failures Status: Identified Impacted Regions: EU01, US01, Tokyo, AP03 (USA) Update (May 5, 2026 - 11:19 AM CDT) We have identified the root cause of the failures affecting Real-time (RT) bulk profile deletion, load, and stitch workflows in the affected regions. Summary of the Issue: A backend configuration issue resulted in a loss of necessary permissions for the service responsible for processing Real-time bulk profile operations. As a result, impacted workflows are failing with an "Authorization" or "400" error when attempting to invoke internal functions. Current Status: Our engineering team has developed a fix and is currently in the process of deploying it to all affected regions. We expect service to be restored shortly after the deployment is completed. We will provide a further update once the fix has been fully deployed and we have confirmed that workflow processing has returned to normal.

2. 5 mai 2026 la 16:23 UTCidentified

   We are continuing to work on a fix for this issue.

3. 5 mai 2026 la 17:43 UTCresolved

   We have applied the fix, and are observing that traffic is flowing correctly now.

1. 27 aprilie 2026 la 17:31 UTCmonitoring

   Between 8:05 AM and 8:30 AM PDT, customers operating in the EU01 (Europe) region may have experienced intermittent errors (5xx) affecting two primary areas: Data Ingestion: Errors when attempting to send records via the Ingest API. Real-Time Personalization: Request failures for personalization and profile lookup services. The disruption was caused by an service interruption with an upstream provider in our data processing layer within the eu-central-1 region. This prevented our systems from successfully persisting incoming data to our streaming infrastructure and executing real-time lookups during the affected window. The upstream provider has confirmed the issue is resolved. Our engineering team monitored the recovery, and we have confirmed that all services in the EU01 region have returned to normal operating parameters. Data Integrity: For data ingestion, records that were rejected with a retryable error code during this window should be resubmitted. Records that have already been successfully ingested following the recovery require no further action. Personalization: Real-time request success rates have returned to 100%. We are continuing to monitor the stability of the region. We apologize for any inconvenience this may have caused to your operations. For further questions, please contact our support team at [email protected].

2. 27 aprilie 2026 la 18:25 UTCresolved

   The upstream provider has restored service.

1. 18 februarie 2026 la 20:45 UTCinvestigating

   We are investigating a possible problem currently affecting Treasure Insights. We will provide an update as soon as we know more.

2. 18 februarie 2026 la 21:27 UTCidentified

   We have partially resolved the incident. We are continuously working to resolve the incident.

3. 18 februarie 2026 la 21:32 UTCmonitoring

   The performance went back to normal, and no errors are observed now. We will monitor at least for 15 minutes.

4. 18 februarie 2026 la 22:00 UTCresolved

   This incident has been resolved.

1. 21 ianuarie 2026 la 02:55 UTCinvestigating

   Starting at approximately 17:00 PST, we observed increased latency affecting all operations accessing table resources in Plazma. At around 19:00 PST, we applied temporary tuning to the database managing table resources and confirmed recovery based on internal performance metrics. We are currently continuing to monitor the system to ensure overall performance remains stable. Visible impacts are: - Streaming, Mobile, and JavaScript/Browser imports may delay - Jobs execution may delay - Table creation may error - Console execution may delay - Plazma Public API may return errors - Treasure Workflow may delay and fail - Workflow REST API may be unavailable - Workflow operations in Console and CLI may become unavailable - Presto JDBC/ODBC queries and CDP segmentation queries may fail - Console Table preview update may delay - The REST API to submit and cancel jobs may be unavailable - Data Connector Integrations may become unavailable - ADH (Ads Data Hub) and DCR (Data Clean Room) service may be unavailable - ADL (Active Data Layer) service may be unavailable We will send an additional update in 30 minutes

2. 21 ianuarie 2026 la 03:37 UTCidentified

   We identified the same issue in the Tokyo region and applied database parameter tuning. We are currently assessing the impact of this change on system performance. As a result of this temporary mitigation applied in both the US and Tokyo regions, the following impact is observed: In Data Workbench, updates to table metadata for row counts and preview data are temporarily paused. We will continue monitoring and provide further updates as we make progress.

3. 21 ianuarie 2026 la 03:40 UTCidentified

   We are continuing to work on a fix for this issue.

4. 21 ianuarie 2026 la 04:06 UTCidentified

   Performance in the Tokyo region improved at approximately 12:50 JST. The Tokyo region had been experiencing gradually increasing performance degradation since around 09:00 JST. We are currently proceeding with the steps to resume updates of table metadata in Data Workbench. Due to the temporary pause of metadata updates, application metrics that rely on this information, such as Parent Segment size, have also been temporarily not updated. We will continue monitoring the system and share further updates as needed.

5. 21 ianuarie 2026 la 04:12 UTCidentified

   In the US region, table metadata updates have been resumed. At this point, the system in the US region is expected to be fully recovered, and we are continuing to monitor it closely. For the Tokyo region, metadata updates will be resumed after we complete confirmation of system performance. We will provide another update when this step begins.

6. 21 ianuarie 2026 la 04:41 UTCmonitoring

   The system in the US region is operating normally with no observed issues. In the Tokyo region, table metadata updates have also been resumed. At this point, the Tokyo region is expected to be fully recovered, and we will continue to monitor system performance. Once stability is fully confirmed, we plan to close this status page.

7. 21 ianuarie 2026 la 05:07 UTCresolved

   Incident Impact Summary (Plazma / Table Resources) We have confirmed that the system in the Tokyo region is operating normally with no remaining issues. What happened - All operations accessing Plazma table resources experienced increased latency. When - US region: 17:00 PST – 18:40 PST - Tokyo region: 09:00 JST – 12:50 JST Temporary impact during recovery - Updates to table row counts and preview data were temporarily paused. Recovery status - US region: Table metadata updates resumed at 20:00 PST. - Tokyo region: Table metadata updates resumed at 13:40 JST. Both regions are now fully recovered. Data integrity - No data loss or data corruption occurred. We will prepare and publish a post-mortem document to explain the circumstances under which this incident occurred one day after the recent system maintenance. With this confirmation, the incident is now closed.

8. 26 ianuarie 2026 la 18:36 UTCpostmortem

   ## Post-Mortem Summary This incident was related to a database maintenance performed on January 19, during which management of Plazma table resources was migrated from the existing RDBMS to a dedicated Aurora database. The purpose of this change was to better isolate table resource workloads and improve long-term scalability. The migration itself completed successfully, and both the original database and the newly introduced Aurora database were operating normally immediately after the maintenance. On the following day, when internal batch processes began running, the newly introduced database experienced unexpected load. Investigation determined that the internal batch system was configured to connect to the master database endpoint instead of a reader endpoint. As a result, internal batch processing competed with user-facing requests, causing increased latency when accessing table resources. To mitigate the impact and enable rapid recovery, temporary database tuning was applied. This tuning was intended solely as a short-term measure to stabilize the system and has since been fully reverted. The permanent fix consisted of correcting the configuration of the internal batch system so that it accesses the appropriate database endpoint. Following these actions, system performance recovered in both the US and Tokyo regions, and all services returned to normal operation. No data loss or data corruption occurred. To prevent similar issues in the future, we are reviewing our configuration and deployment practices, including reducing configuration differences between staging and production environments and strengthening validation of database endpoints used by internal workloads.

1. 10 decembrie 2025 la 06:03 UTCresolved

   An unexpected behavior occurred in the REST API "GET /v3/job/result/{job_id}" which caused it to return only a partial set of results. This issue stemmed from an update to the job result download mechanism implemented around 2025/12/09 01:00 (UTC). The issue was resolved after a fix was applied around 2025/12/10 04:36(UTC). The affected API is used through the following methods: - Directly calling the REST API - Using functions in libraries (e.g., pytd) that reference job results - Toolbelt commands that refers to job results - Setting store_last_results:true in the td>:/td_run> operator in Treasure Workflows - Using the td_for_each>, td_wait> and td_wait_table>: operators in Treasure Workflows Unfortunately, we are unable to identify which API requests were affected. Please compare the number of results retrieved by your job with the download results to see if you were affected. We sincerely apologize for the inconvenience this has caused.

1. 5 decembrie 2025 la 09:18 UTCinvestigating

   We are currently experiencing issues accessing Treasure Insights. Our investigation has identified that this is caused by an outage with a third-party service provider utilized by Treasure Insights. We are monitoring the situation and working with the provider to resolve the issue. We will provide updates as soon as more information becomes available.

2. 5 decembrie 2025 la 09:22 UTCmonitoring

   The third-party service provider has implemented a fix. We are monitoring the results.

3. 5 decembrie 2025 la 09:30 UTCresolved

   We confirmed the third-party service is now operational. The incident has been resolved.

1. 5 noiembrie 2025 la 03:49 UTCinvestigating

   We have encountered a temporary issue with the availability of Premium Audit Logs for Artificial Intelligence services (AI Agent Foundry and Audience Agent) during the period of November 4th 23:19:26 UTC to November 5th 00:57:55 UTC. While some data during this period may not have been captured, our engineering team is actively investigating the situation. We are taking all necessary steps to restore full service and ensure that all future logs are recorded without issue. We apologize for any inconvenience this may have caused and will keep you updated on our progress.

2. 5 noiembrie 2025 la 03:55 UTCmonitoring

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

3. 5 noiembrie 2025 la 07:58 UTCresolved

   Services have been restored to normal operations, and all of our systems are reporting healthy once again. If you observe any lingering issues, please connect with our support team, and we would be happy to help: https://docs.treasuredata.com/articles/#!pd/contacting-treasure-data-support

1. 20 octombrie 2025 la 08:53 UTCinvestigating

   We are aware of an issue affecting log writing and reading for the Profile API in all regions. This is due to an incident with an upstream service. Our team is monitoring the provider's status. We will provide an update shortly.

2. 20 octombrie 2025 la 10:15 UTCinvestigating

   We are also investigating reports indicating that this incident might be causing login errors for customers using SSO (Single Sign-On) to log into our service. Customers attempting a new login via SSO may be unable to access the service. We believe users who are already logged in (have an active session) and users logging in with methods other than SSO (e.g., username/password) are not affected by this login issue. We are working to confirm this.

3. 20 octombrie 2025 la 15:09 UTCinvestigating

   Our upstream service provider is gradually recovering its services, and our services are gradually recovering too. SSO login is working fine, however profile API 1.0 is still recovering its service with latency. As the upstream service provider incident is still ongoing, you might still encounter unexpected errors or issues. We will closely monitoring our services and work with our upstream service provider.

4. 20 octombrie 2025 la 18:53 UTCidentified

   We are continuing to work with our service provider to track this issue. Customers may continue to observe higher latency than normal and may notice delays in processing. We are monitoring the situation closely and are adding additional capacity in anticipation of a recovery. As this situation develops, we will keep you updated on any changes in expected behavior.

5. 20 octombrie 2025 la 21:32 UTCresolved

   Delays should be improving for all customers, and services should be returning to normal. Given the similarity of the two issues, we'll continue tracking any concerns related to this interruption as part of the "[US Region] Issue Affecting Treasure Data Services" issue. For further updates, please track here: https://status.treasuredata.com/incidents/w7v5wtmkdllj If you experience continued issues specifically relating to our Profiles API or SSO Logins, please contact our support team: https://docs.treasuredata.com/articles/#!pd/contacting-treasure-data-support

1. 20 octombrie 2025 la 08:27 UTCinvestigating

   We are currently investigating an issue originating from an upstream service provider used by our infrastructure. This may be affecting the normal operation of some Treasure Data services. We are working to determine the scope of the impact. Observed symptoms may include, but are not limited to, the failure of various jobs (such as Trino, Hive, Result Export, Import, and Custom Script execution) to start. Our team is actively monitoring the situation and working with the provider. We will provide further updates as more information becomes available.

2. 20 octombrie 2025 la 15:05 UTCinvestigating

   Our upstream service provider is gradually recovering its services, and our services are gradually recovering too. Most of our Treasure Data services are back to normal except for Custom Script, autoML and realtime services such as profile API 1.0, and realtime 2.0. As the upstream service provider incident is still ongoing, you might still encounter unexpected errors or issues. We will closely monitoring our services and work with our upstream service provider.

3. 20 octombrie 2025 la 18:49 UTCinvestigating

   We are continuing to monitor ongoing recovery efforts, and most of our systems remain operating. As the situation with our upstream provider develops we will react if we discover any new issues. At this time, we are observing delays in our systems, including Profile API 1.0 and Realtime 2.0. Requests are being processed as they have been received, but users may see a slowdown in results, and may notice delays when updating configurations or journeys. You may notice continued slower performance or unexpected errors. We are working with our service provider to address these issues and will provide an update with new information soon.

4. 20 octombrie 2025 la 19:35 UTCmonitoring

   We are seeing continued recovery across our systems, and are currently working to process any buffered or delayed messages. Customers may continue to observe delays in data processing and may notice slower-than-usual processing of configuration changes. We expect these delays to decrease as our systems catch up. Our team is continuing to track recovery closely, and we'll inform you of any new developments.

5. 20 octombrie 2025 la 21:42 UTCmonitoring

   Service levels continue to improve as upstream services become more stable. Users may still see processing delays, though those should be decreasing as we process the backlog of messages from this event. We are continuing to monitor our systems and deploy capacity as needed. We will update you with additional information as it develops.

6. 20 octombrie 2025 la 23:15 UTCresolved

   Services have been restored to normal operations, and all of our systems are reporting healthy once again. If you observe any lingering issues, please connect with our support team, and we would be happy to help: https://docs.treasuredata.com/articles/#!pd/contacting-treasure-data-support