Historique des pannes de Treasure Data

1. 22 octobre 2026 à 03:24 UTCidentified

   Depuis le 13 octobre, 2026 02:00 UTC, certains travaux d'importation qui lisent les fichiers Parquet d'Amazon S3 complètent avec succès mais chargent les colonnes de date et d'heure en texte (chaîne) au lieu de nombres (long). Si la table de destination définit déjà ces colonnes aussi longtemps, les valeurs importées sont vides (NULL). Seules les colonnes stockées avec un type de date ou d'heure dans le fichier Parquet sont affectées. Les autres colonnes et autres connecteurs de données ne sont pas affectés. Nous avons identifié la cause, un changement introduit dans la version du 13 octobre, et nous préparons une correction. Nous évaluons l'ampleur de l'impact. Nous fournirons une mise à jour dans 30 minutes.

2. 22 octobre 2026 à 04:06 UTCidentified

   Nous avons identifié la cause des importations d'Amazon S3 Parquet date de chargement et colonnes de temps comme texte (chaîne) au lieu de nombres (long) depuis le 13 octobre 2026 02:00 UTC, et nous mettons en œuvre une correction. Jusqu'à ce que la correction soit déployée, les travaux d'importation affectés continuent de compléter avec succès ces colonnes chargées en texte. Les autres colonnes et autres connecteurs de données ne sont pas affectés. Nous vérifions l'intégrité des données importées pendant cette période. Nous fournirons une mise à jour dans 1 heure.

3. 22 octobre 2026 à 06:22 UTCidentified

   Nous avons identifié la cause des importations d'Amazon S3 Parquet date de chargement et colonnes d'heure comme texte (chaîne) au lieu de nombres (long) depuis le 13 octobre 2026 02:00 UTC, et déployons une correction. Jusqu'à ce que la correction soit déployée, les travaux d'importation affectés continuent de compléter ces colonnes chargées en texte. Les autres colonnes et autres connecteurs de données ne sont pas affectés. Nous vérifions l'intégrité des données importées pendant cette période. Nous fournirons une mise à jour dans 30 minutes.

4. 22 octobre 2026 à 07:44 UTCmonitoring

   Nous avons déployé un correctif pour Amazon S3 Parquet importe la date et l'heure de chargement des colonnes comme texte. Les nouveaux emplois d'importation chargent ces colonnes en chiffres (longs), comme avant le 13 octobre 2026. Nous veillons à assurer la stabilité. Nous fournirons une mise à jour dans 30 minutes.

5. 22 octobre 2026 à 10:15 UTCresolved

   La question qui a amené les importations d'Amazon S3 Parquet à charger des colonnes de date et d'heure sous forme de texte (chaîne) au lieu de nombres (long) a été résolue. Une correction a été déployée le 22 octobre 2026 à 07h40 UTC, et de nouveaux emplois d'importation chargent ces colonnes en chiffres (long), comme avant le 13 octobre 2026. Les données importées entre le 13 octobre 2026 02:00 UTC et le 22 octobre 2026 07:40 UTC peuvent contenir des colonnes de date et d'heure touchées. Nous contacterons directement les clients concernés. Nous nous excusons pour le désagrément et vous remercions de votre patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 octobre 2026 à 04:21 UTCidentified

   Depuis environ 22:55 UTC le 6 octobre, les utilisateurs de l'application mobile Treasure AI Voice peuvent être incapables de transférer de nouveaux enregistrements de leur appareil. Le transfert échoue avec une erreur « non autorisée ». Cela affecte les transferts Wi-Fi et Bluetooth. Nous avons identifié la cause et déployons une solution. Les enregistrements déjà transférés, ainsi que leurs transcriptions et résumés, ne sont pas touchés. Nous fournirons une mise à jour dans 30 minutes.

2. 7 octobre 2026 à 04:27 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

3. 7 octobre 2026 à 04:54 UTCmonitoring

   Nous avons déployé une correction côté serveur pour les échecs de transfert d'enregistrement dans Treasure AI Voice. Les nouveaux transferts depuis l'application mobile sont à nouveau couronnés de succès. Aucune mise à jour d'application n'est requise. Les enregistrements qui n'ont pas été transférés pendant l'incident peuvent être transférés à nouveau de l'appareil. Nous veillons à assurer la stabilité.

4. 7 octobre 2026 à 05:24 UTCresolved

   Les échecs de transfert d'enregistrement dans Treasure AI Voice ont été résolus. Tous les systèmes fonctionnent normalement. Entre environ 22h55 UTC le 6 octobre et [heure fixe] UTC le 7 octobre, de nouveaux enregistrements n'ont pas pu être transférés de l'application mobile. Nous avons déployé une correction côté serveur, et aucune mise à jour de l'application n'est requise. Les enregistrements qui n'ont pas été transférés pendant cette période peuvent être transférés à nouveau de l'appareil. Merci de votre patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 30 septembre 2026 à 04:36 UTCresolved

   Entre le 28 septembre (5h30 UTC) et le 29 septembre (6h30 UTC) les clients sans segments de lots qui avaient programmé des mises à jour d'attribut auraient vu des tâches échouées empêchant le chargement des données de lots dans Reactor. Les clients auraient vu des erreurs en attendant les modifications de configuration à mettre à jour. L'impact est toute application en temps réel, les personnalisations, ou les campagnes pendant cette fenêtre peut avoir compté sur des données d'attributs de lots statiques. Le système a récupéré et les workflows envoient maintenant des données actualisées.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 29 septembre 2026 à 17:22 UTCinvestigating

   Nous enquêtons actuellement sur les emplois d'exportation par lots qui ne chargent pas les données dans le réacteur de la région américaine (AWS). Les mises à jour des données seront retardées jusqu'à 24 heures. Nous mettrons à jour l'état dans une heure.

2. 29 septembre 2026 à 18:20 UTCmonitoring

   Un correctif a été mis en place et nous avons constaté que les emplois réussissent.

3. 29 septembre 2026 à 21:18 UTCresolved

   Cet incident a été résolu, et notre équipe de soutien suivra avec les clients touchés.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 28 septembre 2026 à 03:41 UTCinvestigating

   Nous sommes actuellement confrontés à un problème avec notre fonctionnalité Live Chat pour les plans d'assistance Corporate et Enterprise. Notre équipe enquête activement. Vous pouvez toujours joindre notre équipe de support comme d'habitude en envoyant un courriel à [email protected]. Nous apprécions votre patience et nous excusons pour tout désagrément.

2. 28 septembre 2026 à 13:16 UTCresolved

   Nous avons identifié et résolu le problème touchant la fonctionnalité Live Chat pour les plans d'aide aux entreprises et aux entreprises. Le service a été entièrement restauré et fonctionne normalement. Nous nous excusons sincèrement de tout inconvénient que cela pourrait avoir causé et nous vous remercions de votre patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 septembre 2026 à 03:14 UTCidentified

   Nous avons identifié la cause des retards affectant les courriels transactionnels de notre interface Web et nous travaillons sur une solution. Les clients peuvent recevoir des courriels plus tard que prévu pendant cette période. Les courriels touchés comprennent les notifications système et les demandes de réinitialisation du mot de passe. D'autres services de messagerie fonctionnent normalement. Nous fournirons une autre mise à jour dans les 30 minutes.

2. 17 septembre 2026 à 03:44 UTCmonitoring

   La livraison transactionnelle d'emails se rétablit, mais il peut prendre un certain temps pour revenir à des niveaux normaux. Nous continuons de surveiller le service. D'autres services de messagerie demeurent inchangés. Nous fournirons une autre mise à jour dans les 2 heures.

3. 17 septembre 2026 à 06:10 UTCmonitoring

   La livraison transactionnelle d'emails se rétablit, mais il peut prendre un certain temps pour revenir à des niveaux normaux. Nous continuons de surveiller le service. D'autres services de messagerie demeurent inchangés. Nous fournirons une autre mise à jour dans les 24 heures.

4. 18 septembre 2026 à 06:51 UTCmonitoring

   La livraison transactionnelle d'emails se rétablit, mais il peut prendre un certain temps pour revenir à des niveaux normaux. L'exécution continue de s'améliorer régulièrement. Nous continuons de surveiller le service. D'autres services de messagerie demeurent inchangés. Nous fournirons une autre mise à jour dans les 7 jours.

5. 25 septembre 2026 à 04:44 UTCmonitoring

   La livraison de courriels transactionnels continue de se rétablir, mais il peut prendre un certain temps pour revenir à des niveaux normaux. La prestation demeure stable et nous continuons de surveiller le service. D'autres services de messagerie demeurent inchangés. Nous fournirons une autre mise à jour dans les sept jours, ou plus tôt si les conditions changent.

6. 5 octobre 2026 à 02:19 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

7. 5 octobre 2026 à 02:20 UTCmonitoring

   La livraison de courriels transactionnels continue de se rétablir, mais il peut prendre un certain temps pour revenir à des niveaux normaux. La prestation demeure stable et nous continuons de surveiller le service. D'autres services de messagerie demeurent inchangés. Nous fournirons une autre mise à jour dans les 14 jours, ou plus tôt si les conditions changent.

8. 16 octobre 2026 à 00:04 UTCresolved

   Nous n'observons plus de retards de livraison. Nous avons amélioré notre surveillance et continuerons de surveiller les perturbations. Si vous remarquez une livraison lente, veuillez contacter notre équipe de support pour obtenir de l'aide.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 27 juillet 2026 à 08:29 UTCresolved

   Entre 7/25 et aujourd'hui, 7/27 à 11:30 JST, nous avons connu un problème de dégradation des performances affectant BulkLoad (Data Connector Import), Result Export (Activation) et Bulk Import. À la suite des rapports reçus ce matin, notre équipe d'ingénieurs a étudié la question et identifié la charge élevée du système dans des conditions spécifiques (retard croissant dans la communication des composants internes) comme étant la cause principale. Le problème a été résolu par rotation complète de nos nœuds de serveur, et la pleine performance a été rétablie à partir de 11:30 AM JST. Nous nous excusons sincèrement pour tout désagrément causé. Nous examinons actuellement nos règles de surveillance et d'alerte afin d'éviter des problèmes similaires à l'avenir.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 juillet 2026 à 17:04 UTCinvestigating

   Nous observons des performances dégradées dans Treasure Work et tdx dans la région de Tokyo. Ce numéro est limité au modèle Claude Haiku 4.5 dans la région de Tokyo seulement. Les utilisateurs peuvent remarquer que les demandes utilisent Claude Haiku 4.5 erreurs de retour ou de délai. Pour le moment, nous ne voyons aucun problème avec d'autres modèles. Comme solution de rechange, les utilisateurs peuvent choisir un modèle différent. Nous enquêtons activement sur cette question et nous nous efforcerons de la mettre à jour dans 30 minutes.

2. 7 juillet 2026 à 17:40 UTCinvestigating

   Nous continuons d'enquêter sur cette question et nous fournirons une autre mise à jour dans 30 minutes.

3. 7 juillet 2026 à 18:07 UTCidentified

   Nous continuons d'étudier cette question et nous évaluons actuellement une solution possible. Nous mettrons à jour dès que nos tests seront terminés.

4. 7 juillet 2026 à 19:42 UTCidentified

   Nous continuons de travailler à la recherche d'une solution et à la détermination de tout facteur contributif potentiel. Encore une fois, comme le problème est localisé aux modèles Haiku 4.5 dans la région de Tokyo, nous recommandons aux utilisateurs d'utiliser temporairement un autre modèle s'ils connaissent des taux d'erreur élevés. Nous nous excusons pour le désagrément et nous aurons bientôt une autre mise à jour.

5. 7 juillet 2026 à 20:27 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

6. 7 juillet 2026 à 20:59 UTCresolved

   Cette question a été résolue. Treasure Work et tdx fonctionnent normalement, et le modèle Claude Haiku 4.5 de la région de Tokyo ne connaît plus d'erreurs ou de chronométrages. Merci de votre patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 26 juin 2026 à 21:48 UTCidentified

   Nous vivons une dégradation des performances des requêtes Hive dans la région américaine. Ce numéro a commencé le 25 juin 2026. Les utilisateurs peuvent observer des temps d'exécution de la requête plus longs que prévu, en particulier pour les tâches à long terme avec de grands volumes de données. Nous avons identifié la cause et nous travaillons sur une solution. Nous fournirons une mise à jour dans 30 minutes.

2. 26 juin 2026 à 22:22 UTCidentified

   Nous vivons une dégradation des performances des requêtes Hive dans la région américaine. Ce numéro a commencé le 25 juin 2026. Les utilisateurs peuvent observer des temps d'exécution de la requête plus longs que prévu, en particulier pour les tâches à long terme avec de grands volumes de données. Nous avons identifié la cause. Pour y remédier, nous validons un changement de configuration de cluster avant de l'appliquer à l'environnement de production. Nous fournirons une mise à jour dans 30 minutes.

3. 26 juin 2026 à 22:57 UTCidentified

   Nous continuons de travailler sur une solution. Notre équipe valide un changement de configuration avant de l'appliquer à l'environnement de production. Nous fournirons une mise à jour dans 30 minutes.

4. 26 juin 2026 à 23:57 UTCmonitoring

   Nous avons fourni un nouveau cluster avec une capacité suffisante et nous y acheminons maintenant des emplois. On s'attend à ce que la performance des requêtes se rétablisse progressivement à mesure que le groupe se stabilise. Nous suivons la situation de près. Nous fournirons une mise à jour dans 1 heure.

5. 27 juin 2026 à 01:13 UTCresolved

   La dégradation de la performance des requêtes de sauvetage dans la région américaine a été résolue. Nous avons réussi à fournir un nouveau cluster et acheminé tout le trafic vers lui. Les systèmes fonctionnent maintenant normalement. Merci de votre patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 25 juin 2026 à 11:46 UTCresolved

   Résolue — Certains emplois d'exportation de résultats (exportation de données) aux États-Unis, à Tokyo et dans les régions de l'UE peuvent avoir échoué ou avoir été retardés entre le 24 juin 2026 21:00 UTC et le 25 juin 2026 05:26 UTC. Au cours de cette période, les nœuds de calcul sous-jacents étaient intermittents et instables, ce qui pourrait entraîner la cessation des travaux d'exportation avant d'être terminés. Dans certains cas, un emploi touché peut avoir pris fin sans message d'erreur clair. Le problème a été résolu et tous les systèmes fonctionnent normalement. L'intégrité des données n'est pas affectée — les données sources dans Treasure Data n'ont pas été affectées; seule la livraison d'emplois d'exportation vers des destinations extérieures pendant cette fenêtre aurait pu être perturbée. Si vous avez exécuté une exportation de résultats/données pendant cette fenêtre, nous vous recommandons de la confirmer complétée et de la relancer si la sortie semble incomplète. Nous contacterons également directement les clients concernés. Merci de votre patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juin 2026 à 11:11 UTCresolved

   Nous avons identifié un retard dans l'enregistrement des données de l'événement e-mail (comme ouvrir, cliquer, rebondir, les événements de livraison et les événements d'erreur) aux tables d'événements clients. Période affectée (approximative): - 22 juin, 03:45 UTC – 23 juin, 04:15 UTC - 23 juin, 07:00 UTC – 24 juin, 07:30 UTC Pendant ces périodes, l'enregistrement des données de l'événement par courriel a été retardé. La livraison du courriel n'a pas été affectée — les courriels ont été envoyés et reçus normalement. Le problème a été résolu et tous les systèmes fonctionnent normalement. Les événements retardés ont été entièrement traités. Si vous avez lancé des requêtes sur des tables event ou error event pendant les périodes concernées, nous vous suggérons de réinitialiser ces requêtes pour obtenir des résultats précis. Nous nous excusons pour tout désagrément.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 5 mai 2026 à 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 à 16:23 UTCidentified

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

3. 5 mai 2026 à 17:43 UTCresolved

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

1. 27 avril 2026 à 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 avril 2026 à 18:25 UTCresolved

   The upstream provider has restored service.

1. 18 février 2026 à 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 février 2026 à 21:27 UTCidentified

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

3. 18 février 2026 à 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 février 2026 à 22:00 UTCresolved

   This incident has been resolved.

1. 21 janvier 2026 à 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 janvier 2026 à 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 janvier 2026 à 03:40 UTCidentified

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

4. 21 janvier 2026 à 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 janvier 2026 à 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 janvier 2026 à 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 janvier 2026 à 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 janvier 2026 à 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 décembre 2025 à 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 décembre 2025 à 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 décembre 2025 à 09:22 UTCmonitoring

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

3. 5 décembre 2025 à 09:30 UTCresolved

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

1. 5 novembre 2025 à 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 novembre 2025 à 03:55 UTCmonitoring

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

3. 5 novembre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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 octobre 2025 à 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