Störungsverlauf von Treasure Data

1. 22. Oktober 2026 um 03:24 UTCidentified

   Seit dem 13. Oktober 2026 02:00 UTC werden einige Importaufträge, die Parkettdateien von Amazon S3 lesen, erfolgreich abgeschlossen, aber Datums- und Zeitspalten als Text (String) anstelle von Zahlen (long) geladen. Wenn die Zieltabelle diese Spalten bereits als lang definiert, sind die importierten Werte leer (NULL). Nur Spalten, die mit einem Datums- oder Uhrzeittyp in der Parquet-Datei gespeichert sind, sind betroffen. Andere Spalten und andere Datenverbinder sind nicht betroffen. Wir haben die Ursache identifiziert, eine Änderung, die im Release vom 13. Oktober eingeführt wurde, und bereiten einen Fix vor. Wir prüfen den vollen Umfang der Auswirkungen. Wir werden in 30 Minuten ein Update bereitstellen.

2. 22. Oktober 2026 um 04:06 UTCidentified

   Wir haben die Ursache für Amazon S3 Parquet Importe Ladedatum und -uhrzeit Spalten als Text (String) anstelle von Zahlen (lang) seit dem 13. Oktober 2026 02:00 UTC identifiziert und implementieren einen Fix. Bis zur Bereitstellung des Fixes werden betroffene Importjobs weiterhin erfolgreich abgeschlossen, wobei diese Spalten als Text geladen werden. Andere Spalten und andere Datenverbinder sind nicht betroffen. Wir überprüfen die Datenintegrität für Daten, die in diesem Zeitraum importiert wurden. Wir werden ein Update in 1 Stunde zur Verfügung stellen.

3. 22. Oktober 2026 um 06:22 UTCidentified

   Wir haben die Ursache für Amazon S3 Parquet-Import-Ladedatums- und -uhrzeitspalten als Text (String) anstelle von Zahlen (lang) seit dem 13. Oktober 2026 02:00 UTC identifiziert und stellen einen Fix bereit. Bis zur Bereitstellung des Fixes werden die betroffenen Importjobs weiterhin mit diesen Spalten als Text geladen. Andere Spalten und andere Datenverbinder sind nicht betroffen. Wir überprüfen die Datenintegrität für Daten, die in diesem Zeitraum importiert wurden. Wir werden in 30 Minuten ein Update bereitstellen.

4. 22. Oktober 2026 um 07:44 UTCmonitoring

   Wir haben einen Fix für Amazon S3 Parquet Importe Ladedatum und Uhrzeit Spalten als Text bereitgestellt. Neue Importjobs laden diese Spalten als Zahlen (lang), wie vor dem 13. Oktober 2026. Wir überwachen die Stabilität. Wir werden in 30 Minuten ein Update bereitstellen.

5. 22. Oktober 2026 um 10:15 UTCresolved

   Das Problem, dass Amazon S3 Parquet-Importe Datums- und Zeitspalten als Text (String) anstelle von Zahlen (long) laden, wurde behoben. Ein Fix wurde am 22. Oktober 2026 um 07:40 UTC eingesetzt, und neue Importjobs laden diese Spalten als Zahlen (lang), wie vor dem 13. Oktober 2026. Daten, die zwischen dem 13. Oktober 2026 02:00 UTC und dem 22. Oktober 2026 07:40 UTC importiert wurden, können betroffene Datums- und Zeitspalten enthalten. Wir werden betroffene Kunden direkt kontaktieren. Wir entschuldigen uns für die Unannehmlichkeiten und danken Ihnen für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Oktober 2026 um 04:21 UTCidentified

   Seit ca. 22:55 UTC am 6. Oktober können Benutzer der Treasure AI Voice Mobile App möglicherweise keine neuen Aufnahmen von ihrem Gerät übertragen. Die Übertragung schlägt mit einem "Nicht autorisierten" Fehler fehl. Dies betrifft sowohl Wi-Fi als auch Bluetooth-Übertragungen. Wir haben die Ursache identifiziert und setzen einen Fix ein. Aufzeichnungen, die bereits übertragen wurden, und ihre Transkripte und Zusammenfassungen sind nicht betroffen. Wir werden in 30 Minuten ein Update bereitstellen.

2. 7. Oktober 2026 um 04:27 UTCidentified

   Wir arbeiten weiter an einer Lösung für dieses Problem.

3. 7. Oktober 2026 um 04:54 UTCmonitoring

   Wir haben eine serverseitige Korrektur für die Aufzeichnung von Übertragungsfehlern in Treasure AI Voice bereitgestellt. Neue Transfers aus der mobilen App sind wieder erfolgreich. Es ist kein App-Update erforderlich. Aufzeichnungen, die während des Vorfalls nicht übertragen wurden, können vom Gerät erneut übertragen werden. Wir überwachen die Stabilität.

4. 7. Oktober 2026 um 05:24 UTCresolved

   Die Aufzeichnungsfehler in Treasure AI Voice wurden behoben. Alle Systeme funktionieren normal. Zwischen ca. 22:55 UTC am 6. Oktober und [fix time] UTC am 7. Oktober konnten keine neuen Aufnahmen von der mobilen App übertragen werden. Wir haben einen serverseitigen Fix bereitgestellt, und es ist kein App-Update erforderlich. Aufzeichnungen, die während dieses Zeitraums nicht übertragen wurden, können wieder vom Gerät übertragen werden. Vielen Dank für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 30. September 2026 um 04:36 UTCresolved

   Zwischen dem 28. September (5:30 Uhr UTC) und dem 29. September (6:30 Uhr UTC) hätten Kunden ohne Batch-Segmente, die Attribut-Updates geplant hatten, gescheiterte Jobs gesehen, die das Laden von Batchdaten in den Reaktor verhindert hätten. Kunden hätten Fehler gesehen, während sie auf die Aktualisierung der Konfigurationsänderungen gewartet hätten. Die Auswirkungen sind Echtzeitanwendungen, Personalisierungen oder Kampagnen während dieses Fensters, die sich möglicherweise auf veraltete Batch-Attributdaten verlassen haben. Das System wurde wiederhergestellt und Workflows senden nun aktualisierte Daten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. September 2026 um 17:22 UTCinvestigating

   Wir untersuchen derzeit Batch-Export-Jobs, bei denen keine Daten in den Reaktor in der Region USA (AWS) geladen werden. Datenaktualisierungen verzögern sich bis zu 24 Stunden. Wir werden den Status in einer Stunde aktualisieren.

2. 29. September 2026 um 18:20 UTCmonitoring

   Es wurde ein Fix umgesetzt, und wir haben festgestellt, dass Arbeitsplätze erfolgreich sind.

3. 29. September 2026 um 21:18 UTCresolved

   Dieser vorfall wurde behoben, und unser support-team wird die betroffenen kunden verfolgen.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 28. September 2026 um 03:41 UTCinvestigating

   Wir haben derzeit ein problem mit unserer live-chat-funktion für corporate- und enterprise-supportpläne. Unser Team untersucht aktiv. Sie können unser Support-Team weiterhin wie gewohnt erreichen, indem Sie [email protected] per E-Mail kontaktieren. Wir schätzen Ihre Geduld und entschuldigen uns für Unannehmlichkeiten.

2. 28. September 2026 um 13:16 UTCresolved

   Wir haben das problem identifiziert und behoben, das sich auf die live-chat-funktion für corporate- und enterprise-support-pläne auswirkt. Der Service wurde vollständig wiederhergestellt und funktioniert normal. Wir entschuldigen uns aufrichtig für alle Unannehmlichkeiten, die dies verursacht haben könnte, und danken Ihnen für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. September 2026 um 03:14 UTCidentified

   Wir haben die Ursache von Verzögerungen bei Transaktions-E-Mails von unserer Weboberfläche aus identifiziert und arbeiten an einer Lösung. Kunden können einige E-Mails später als erwartet in dieser Zeit erhalten. Betroffene E-Mails umfassen Systembenachrichtigungen und Passwort-Reset-Anforderungen. Andere E-Mail-Dienste funktionieren normal. Wir werden innerhalb von 30 Minuten ein weiteres Update bereitstellen.

2. 17. September 2026 um 03:44 UTCmonitoring

   Die Transaktions-E-Mail-Zustellung erholt sich, aber es kann einige Zeit dauern, bis Sie wieder auf ein normales Niveau zurückkehren. Wir überwachen den Service weiterhin. Andere E-Mail-Dienste bleiben unberührt. Wir werden innerhalb von 2 Stunden ein weiteres Update bereitstellen.

3. 17. September 2026 um 06:10 UTCmonitoring

   Die Transaktions-E-Mail-Zustellung erholt sich, aber es kann einige Zeit dauern, bis Sie wieder auf ein normales Niveau zurückkehren. Wir überwachen den Service weiterhin. Andere E-Mail-Dienste bleiben unberührt. Wir werden innerhalb von 24 Stunden ein weiteres Update bereitstellen.

4. 18. September 2026 um 06:51 UTCmonitoring

   Die Transaktions-E-Mail-Zustellung erholt sich, aber es kann einige Zeit dauern, bis Sie wieder auf ein normales Niveau zurückkehren. Die Lieferung verbessert sich stetig. Wir überwachen den Service weiterhin. Andere E-Mail-Dienste bleiben unberührt. Wir werden innerhalb von 7 Tagen ein weiteres Update bereitstellen.

5. 25. September 2026 um 04:44 UTCmonitoring

   Die Transaktions-E-Mail-Zustellung erholt sich weiter, aber es kann einige Zeit dauern, bis sie wieder auf ein normales Niveau zurückkehrt. Die Lieferung bleibt stabil und wir überwachen den Service weiterhin. Andere E-Mail-Dienste bleiben unberührt. Wir werden innerhalb von sieben Tagen ein weiteres Update bereitstellen, oder früher, wenn sich die Bedingungen ändern.

6. 5. Oktober 2026 um 02:19 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

7. 5. Oktober 2026 um 02:20 UTCmonitoring

   Die Transaktions-E-Mail-Zustellung erholt sich weiter, aber es kann einige Zeit dauern, bis sie wieder auf ein normales Niveau zurückkehrt. Die Lieferung bleibt stabil und wir überwachen den Service weiterhin. Andere E-Mail-Dienste bleiben unberührt. Wir werden innerhalb von 14 Tagen ein weiteres Update bereitstellen, oder früher, wenn sich die Bedingungen ändern.

8. 16. Oktober 2026 um 00:04 UTCresolved

   Wir beobachten keine Lieferverzögerungen mehr. Wir haben unsere Überwachung verbessert und werden weiterhin auf Störungen achten. Wenn sie eine schleppende lieferung bemerken, kontaktieren sie bitte unser support-team für hilfe.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 27. Juli 2026 um 08:29 UTCresolved

   Zwischen 7/25 und heute, 7/27 um 11:30 Uhr JST, hatten wir ein Problem mit Leistungseinbußen bei BulkLoad (Data Connector Import), Result Export (Aktivierung) und Bulk Import. Nachdem heute Morgen Berichte eingegangen waren, untersuchte unser Ingenieurteam das Problem und identifizierte eine hohe Systemlast unter bestimmten Bedingungen (zunehmende Verzögerung bei der Kommunikation interner Komponenten) als Ursache. Das Problem wurde durch vollständige Rotation unserer Serverknoten behoben und die volle Leistung wurde ab 11:30 Uhr JST wiederhergestellt. Wir entschuldigen uns aufrichtig für jegliche Unannehmlichkeiten. Wir überprüfen derzeit unsere Überwachungs- und Alarmierungsregeln, um ähnliche Probleme in Zukunft zu verhindern.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 7. Juli 2026 um 17:04 UTCinvestigating

   Wir beobachten eine verschlechterte Leistung bei Treasure Work und tdx in der Region Tokio. Diese Ausgabe beschränkt sich auf das Modell Claude Haiku 4.5 nur in der Region Tokio. Benutzer können feststellen, dass Anfragen mit Claude Haiku 4.5 Fehler oder Time-Out zurückgeben. Zu diesem Zeitpunkt sehen wir keine Probleme mit anderen Modellen. Als Workaround können Benutzer ein anderes Modell auswählen. Wir untersuchen dieses Problem aktiv und werden versuchen, in 30 Minuten ein Update bereitzustellen.

2. 7. Juli 2026 um 17:40 UTCinvestigating

   Wir untersuchen dieses Problem weiter und werden in 30 Minuten ein weiteres Update bereitstellen.

3. 7. Juli 2026 um 18:07 UTCidentified

   Wir untersuchen dieses Problem weiter und prüfen derzeit eine mögliche Lösung. Wir werden aktualisieren, sobald unsere Tests abgeschlossen sind.

4. 7. Juli 2026 um 19:42 UTCidentified

   Wir arbeiten weiterhin an einer möglichen Lösung und arbeiten daran, mögliche beitragende Faktoren zu identifizieren. Da das Problem auf Haiku 4,5-Modelle in der Region Tokio lokalisiert ist, empfehlen wir Benutzern, vorübergehend ein anderes Modell zu verwenden, wenn erhöhte Fehlerraten auftreten. Wir entschuldigen uns für die Unannehmlichkeiten und werden bald ein weiteres Update haben.

5. 7. Juli 2026 um 20:27 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

6. 7. Juli 2026 um 20:59 UTCresolved

   Dieses Problem ist gelöst. Treasure Work und tdx funktionieren normal, und das Claude Haiku 4.5-Modell in der Region Tokio hat keine Fehler mehr oder Timeouts. Vielen Dank für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 26. Juni 2026 um 21:48 UTCidentified

   Wir erleben eine Verschlechterung der Hive-Abfrageleistung in der US-Region. Dieses Problem begann am 25. Juni 2026. Benutzer können länger als erwartete Abfrageausführungszeiten beobachten, insbesondere bei lang laufenden Jobs mit großen Datenmengen. Wir haben die Ursache identifiziert und arbeiten an einer Lösung. Wir werden in 30 Minuten ein Update bereitstellen.

2. 26. Juni 2026 um 22:22 UTCidentified

   Wir erleben eine Verschlechterung der Hive-Abfrageleistung in der US-Region. Dieses Problem begann am 25. Juni 2026. Benutzer können länger als erwartete Abfrageausführungszeiten beobachten, insbesondere bei lang laufenden Jobs mit großen Datenmengen. Wir haben die Ursache identifiziert. Um dies zu beheben, validieren wir eine Clusterkonfigurationsänderung, bevor wir sie auf die Produktionsumgebung anwenden. Wir werden in 30 Minuten ein Update bereitstellen.

3. 26. Juni 2026 um 22:57 UTCidentified

   Wir arbeiten weiter an einem Fix. Unser Team validiert eine Clusterkonfigurationsänderung, bevor sie auf die Produktionsumgebung angewendet wird. Wir werden in 30 Minuten ein Update bereitstellen.

4. 26. Juni 2026 um 23:57 UTCmonitoring

   Wir haben einen neuen Cluster mit ausreichender Kapazität bereitgestellt und leiten nun Jobs dorthin. Es wird erwartet, dass sich die Abfrageleistung allmählich erholt, wenn sich der Cluster stabilisiert. Wir verfolgen die Situation aufmerksam. Wir werden ein Update in 1 Stunde zur Verfügung stellen.

5. 27. Juni 2026 um 01:13 UTCresolved

   Hive Query Performance Degradation in der US-Region wurde behoben. Wir haben erfolgreich einen neuen Cluster bereitgestellt und den gesamten Traffic dorthin geleitet. Die Systeme funktionieren jetzt normal. Vielen Dank für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 25. Juni 2026 um 11:46 UTCresolved

   Einige Ergebnisexport (Datenexport) Jobs in den USA, Tokio und EU-Regionen sind möglicherweise gescheitert oder wurden zwischen dem 24. Juni 2026 21:00 UTC und dem 25. Juni 2026 05:26 UTC verzögert. Während dieser Zeit waren die zugrunde liegenden Rechenknoten zeitweise instabil, was dazu führen könnte, dass Exportaufträge vor dem Abschluss beendet werden. In einigen Fällen kann ein betroffener Job ohne eine klare Fehlermeldung beendet worden sein. Das Problem wurde behoben und alle Systeme funktionieren normal. Die Datenintegrität ist nicht beeinträchtigt – die Quelldaten in Treasure Data waren nicht betroffen; nur die Lieferung von Exportaufträgen an externe Ziele während dieses Fensters hätte unterbrochen werden können. Wenn Sie in diesem Fenster einen Ergebnis-/Datenexport ausgeführt haben, empfehlen wir, den Abschluss zu bestätigen und erneut auszuführen, wenn die Ausgabe unvollständig aussieht. Wir werden auch betroffene Kunden direkt kontaktieren. Vielen Dank für Ihre Geduld.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. Juni 2026 um 11:11 UTCresolved

   Wir haben eine Verzögerung bei der Aufzeichnung von E-Mail-Ereignisdaten (wie Öffnen, Klicken, Abprallen, Lieferereignisse und Fehlerereignisse) in den Kundenereignistabellen festgestellt. Betroffene Periode (ungefähr): - 22. Juni, 03:45 UTC - 23. Juni, 04:15 UTC - 23. Juni, 07:00 UTC - 24. Juni, 07:30 UTC Während dieser Zeiträume verzögerte sich die Aufzeichnung von E-Mail-Ereignisdaten. Die E-Mail-Zustellung selbst war nicht betroffen - E-Mails wurden normalerweise gesendet und empfangen. Das Problem wurde behoben und alle Systeme funktionieren normal. Verzögerte Ereignisse wurden vollständig verarbeitet. Wenn Sie in den betroffenen Zeiträumen Abfragen zu den Tabellen event oder error event ausgeführt haben, empfehlen wir, diese Abfragen erneut auszuführen, um genaue Ergebnisse zu erhalten. Wir entschuldigen uns für jegliche Unannehmlichkeiten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

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

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

3. 5. Mai 2026 um 17:43 UTCresolved

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

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

   The upstream provider has restored service.

1. 18. Februar 2026 um 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. Februar 2026 um 21:27 UTCidentified

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

3. 18. Februar 2026 um 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. Februar 2026 um 22:00 UTCresolved

   This incident has been resolved.

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

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

4. 21. Januar 2026 um 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. Januar 2026 um 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. Januar 2026 um 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. Januar 2026 um 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. Januar 2026 um 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. Dezember 2025 um 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. Dezember 2025 um 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. Dezember 2025 um 09:22 UTCmonitoring

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

3. 5. Dezember 2025 um 09:30 UTCresolved

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

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

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

3. 5. November 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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. Oktober 2025 um 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