Störungsverlauf von Asana

1. 23. Oktober 2026 um 23:57 UTCinvestigating

   Wir haben eine erhebliche Verschlechterung in unserem System zur Verarbeitung asynchroner Arbeit. Wir hatten zuvor einige Abstürze von Benutzern von Webanwendungen, aber das scheint sich behoben zu haben. Wir überwachen die asynchrone Arbeit.

2. 24. Oktober 2026 um 00:03 UTCmonitoring

   Wir haben einige problematische Workloads angehalten und denken, dass wir eine Erholung sehen.

3. 24. Oktober 2026 um 02:35 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. Oktober 2026 um 15:33 UTCidentified

   Asana-Dienste erleben derzeit eine große Service-Störung. Wir haben eine wahrscheinliche Ursache identifiziert und arbeiten daran, einen Fix anzuwenden. Dies betrifft alle Dienstleistungen und alle Regionen.

2. 21. Oktober 2026 um 15:51 UTCidentified

   Wir haben die Ursache dieses Ausfalls identifiziert und Änderungen eingeleitet, um dies zu beheben. Wir sehen einige Anzeichen einer Erholung und werden ein Update veröffentlichen, sobald wir die Erholung bestätigt haben.

3. 21. Oktober 2026 um 16:08 UTCidentified

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

4. 21. Oktober 2026 um 16:10 UTCresolved

   Der Fix wurde angewendet. Wir haben eine Wiederherstellung der Fehlerquoten und des Datenverkehrs beobachtet und glauben, dass dieser Vorfall nun behoben ist. Wir werden eine Postmortem / RCA innerhalb von 72 Stunden posten.

5. 24. Oktober 2026 um 00:22 UTCpostmortem

   **Vorfall:** Eine auf die Sicherheit ausgerichtete Aktualisierung der Infrastruktur führte dazu, dass DynamoDB in der gesamten Asana-Produktionsumgebung nicht mehr zugänglich war. Diese Änderung stand im Zusammenhang mit einer Produktionsisolierungsinitiative und wurde so angewendet, dass alle unsere Produktionsdienste keine DynamoDB-Tabellen verwenden konnten, die wir für Metadaten und Routing-Datenverkehr verwenden. Sobald die Änderung rückgängig gemacht wurde, kehrten unsere Dienste zum normalen Betrieb zurück. **Auswirkungen:** Asana-Dienste waren für ca. 30 Minuten, 2026-10-21 15:21 UTC-15:51 UTC völlig nicht verfügbar und meist für weitere 20 Minuten nicht verfügbar, einschließlich 15:05 UTC-15:55 UTC. Dies führte auch zu Verzögerungen bei Hintergrundaktionen während der Aufprallzeit; Erholung nach dem Ende des Vorfalls um 16:00 Uhr UTC. **Vorwärtsfahrt:** Wir aktualisieren den Bereitstellungsprozess, um diese Fehlerklasse zu erfassen. Wir werden zu einem Isolationssystem übergehen, das eine schrittweise Einführung ähnlicher Änderungen ermöglicht und es uns ermöglicht, Fehlkonfigurationen bei Vorserientests zu erkennen. Unsere Metrik berücksichtigt einen gewichteten Durchschnitt der Betriebszeit, die Benutzer in jedem Rechenzentrum erleben. Die angezeigte Ausfallzeit in Minuten spiegelt diesen gewichteten Durchschnitt wider.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 30. September 2026 um 14:31 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 30. September 2026 um 15:09 UTCidentified

   Wir sehen derzeit eine Systemwiederherstellung und überwachen die Situation aktiv, um eine vollständige Wiederherstellung zu gewährleisten.

3. 30. September 2026 um 15:21 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. September 2026 um 12:14 UTCinvestigating

   Wir untersuchen das Problem derzeit.

2. 29. September 2026 um 15:25 UTCresolved

   Der Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. September 2026 um 14:59 UTCidentified

   Wir haben Berichte über Regeln und Automatisierungen gehört, die in der EU-Region nicht funktionieren. Wir haben die Ursache des Problems identifiziert und es für neue Automatisierungsauslöser in Zukunft behoben. Unsere Ingenieure arbeiten derzeit am Automatisierungsrückstand, der während des Vorfalls ausgelöst und nicht ausgeführt wurde.

2. 21. September 2026 um 15:00 UTCidentified

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

3. 21. September 2026 um 15:39 UTCmonitoring

   Wir arbeiten uns derzeit durch den Rückstau von Automatisierungen, die nicht ausgeführt wurden.

4. 21. September 2026 um 16:10 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. September 2026 um 14:36 UTCinvestigating

   Wir erhielten eine Warnung für ungewöhnlich langsame Leistung in mehreren Regionen. Wir untersuchen.

2. 17. September 2026 um 15:12 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 17. September 2026 um 15:13 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 2. September 2026 um 18:08 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 2. September 2026 um 18:13 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 2. September 2026 um 18:14 UTCinvestigating

   Der Rollback scheint Fehler vollständig behoben zu haben. Wir beobachten genau, aber Benutzer sollten wieder auf Asana zugreifen können.

4. 2. September 2026 um 18:14 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 2. September 2026 um 18:49 UTCresolved

   Dieser Vorfall wurde behoben.

6. 4. September 2026 um 19:52 UTCpostmortem

   Vorfall: Ein internes System, das für die automatische Skalierung der Backend-Serverkapazität in einem unserer Compute-Cluster verantwortlich ist, hat aufgehört, Kapazitäten zu ersetzen, die während der routinemäßigen Wartung ausgeschöpft wurden. Dies führte zu einer allmählichen Verringerung der verfügbaren Kapazität über mehrere Stunden. Eine nachfolgende Bereitstellung wurde mit unzureichender Kapazität aktiviert, was dazu führte, dass alle neuen Anforderungen für diesen Compute-Cluster fehlschlugen. Um die Auswirkungen abzumildern, haben wir auf eine vorherige Release-Revision zurückgegriffen, die noch über ausreichende Kapazitäten verfügte. Auswirkung: Für etwa 30 Minuten sahen Kunden, deren Datenverkehr von diesem Compute-Cluster abgewickelt wurde, volle Ausfallzeiten; andere Kunden waren nicht betroffen. Es gingen keine Kundendaten verloren. Wir haben zusätzliche Überwachung hinzugefügt, um diese Art von Fehlern bei der Kapazitätsskalierung viel früher zu erkennen, und Sicherheitsvorkehrungen hinzugefügt, um zu verhindern, dass sich der Datenverkehr verlagert, bevor eine ausreichende gesunde Kapazität bestätigt wird. Unsere Metrik berücksichtigt einen gewichteten Durchschnitt der Betriebszeit, die Benutzer in jedem Rechenzentrum erleben. Die angezeigte Ausfallzeit in Minuten spiegelt diesen gewichteten Durchschnitt wider.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. August 2026 um 15:14 UTCinvestigating

   Wir untersuchen Warnungen auf langsame Leistung und Anwendungsfehler.

2. 31. August 2026 um 15:55 UTCinvestigating

   Wir untersuchen das Problem weiter; wir haben die jüngsten Änderungen rückgängig gemacht und arbeiten daran, die Quelle der Fehler zu identifizieren.

3. 31. August 2026 um 16:24 UTCinvestigating

   Wir haben Konfigurationsänderungen vorgenommen und sehen eine teilweise Wiederherstellung, aber wir sehen weiterhin einige erhöhte Fehler.

4. 31. August 2026 um 16:47 UTCmonitoring

   Wir haben einen Fix angewendet sehen Zeichen der Erholung.

5. 31. August 2026 um 17:18 UTCresolved

   User-facing Symptome haben sich erholt. Wir werden weiterhin überwachen und eine Retrospektive priorisieren, um ähnliche Vorfälle in Zukunft zu verstehen und zu verhindern.

6. 2. September 2026 um 21:29 UTCpostmortem

   Wir haben daran gearbeitet, unserer Update-Pipeline eine Caching-Schicht hinzuzufügen, sie sorgfältig abzustimmen und schrittweise auszurollen. Am Mittwoch, den 26. August haben wir es für die meisten Anwendungsfälle aktiviert und es hat anfangs gut funktioniert. Am Montag, dem 31. August, hat eine Kombination aus nicht zusammenhängenden Infrastrukturänderungen und Spitzenverkehr den Cache über seine Skalierungsgrenzen hinausgeschoben. Sobald dieser Schwellenwert überschritten wurde, wurde der Cache unbrauchbar, und viele Pods, die Leseverkehr für die Asana-Anwendung bereitstellen, konnten ihn nicht mehr bedienen. Wir haben den Vorfall abgemildert, indem wir das System auf den vorherigen, nicht zwischengespeicherten Codepfad zurückgesetzt haben. Der Rückschlag war erfolgreich, aber die Erholung dauerte länger, als wir für diese Klasse von Problemen erwarten würden. Eine umfassendere Analyse ist im Gange. Wir werden die Ursachen, Aktionspunkte und Verbesserungen nachverfolgen, einschließlich der Gründe, warum die Genesung so lange gedauert hat. Wir waren für etwa 25% unserer Benutzer für 2 Stunden, 15 Minuten völlig unten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. August 2026 um 17:24 UTCresolved

   From 2026-08-04 15:25 UTC until 2026-08-06 03:51 UTC, Asana failed to send some events to registered webhooks and to return them in the event streams API. Apps which rely on this should refetch the underlying data from the Asana API. Existing webhooks and event streams will continue to function, but events from the incident window will not be sent. Most events with type `task` and action `changed` were dropped during this period. Other events are not affected. The root cause of the incident was traced to a code change which unintentionally dropped change events for most fields on the task type, and the change was reverted.

1. 7. Juli 2026 um 18:49 UTCidentified

   Wir sehen Fehler für einen Teil (ca. 10%) der Benutzer in den USA für die Asana Webapp. Wir haben die Ursache identifiziert und arbeiten daran, eine Lösung zu finden.

2. 7. Juli 2026 um 19:12 UTCmonitoring

   Wir haben eine Abschwächung eingeführt und überwachen die Erholung.

3. 7. Juli 2026 um 19:21 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

4. 7. Juli 2026 um 19:24 UTCresolved

   Dieser Vorfall wurde behoben.

5. 8. Juli 2026 um 21:28 UTCpostmortem

   **Vorfall**: Eine Konfigurationsänderung hat versehentlich eine kritische Ressource entfernt, die von einem unserer Dienste benötigt wird. Während die bestehende Infrastruktur weiterhin normal funktionierte, konnte die neu skalierte Infrastruktur nicht fertig werden. Als der morgendliche Verkehr zunahm, wuchs die Kluft zwischen eingehenden Anfragen und der Fähigkeit unseres Systems, sie zu verarbeiten, was zu einer Verschlechterung des Service führte. Wir haben das Problem behoben, indem wir die fehlende Ressource manuell wiederhergestellt und die Konfigurationsänderung korrigiert haben, die zu ihrer Entfernung geführt hat. **Auswirkungen**: Etwa 1,5 Stunden lang erlebte eine Teilmenge unserer Kunden einen vollständigen Ausfall unserer Web-Anwendungen und Desktop-Anwendungen. Während dieser Zeit konnten betroffene Benutzer nicht auf Asana zugreifen. Es gingen keine Kundendaten verloren. **Vorwärts gehen**: Wir implementieren zusätzliche Sicherheitsvorkehrungen in unserem Konfigurationsmanagementprozess, um zu verhindern, dass kritische Ressourcen versehentlich entfernt werden. Wir verbessern auch unsere Überwachungssysteme, um Degradation früher zu erkennen, bevor sie den Kundenzugang beeinträchtigt. Unsere Metrik berücksichtigt einen gewichteten Durchschnitt der Betriebszeit, die Benutzer in jedem Rechenzentrum erleben. Die angezeigte Ausfallzeit in Minuten spiegelt diesen gewichteten Durchschnitt wider.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. April 2026 um 23:19 UTCresolved

   Between April 21st and April 23rd, many rules triggered by date time triggers did not run. New rule triggers ran normally starting April 23rd, and the delayed triggers were processed by April 27th.

2. 30. April 2026 um 00:43 UTCpostmortem

   Starting on **April 20th, 2026 at 10:00 AM PDT**, a combination of scaled-up background action jobs in the EU and a recent change to how date time trigger volume is managed overloaded the system that processes resource intensive background action jobs. This caused multi-hour delays in email and inbox notifications in the EU and prevented date time triggers from executing in all regions. Engineers were first alerted on **April 21st** by our monitoring systems, but did not recognize the full scope of the incident until **April 23rd**. On April 23rd, the change to manage date time trigger volume was reverted and the problematic background action jobs were isolated. All delayed notifications were sent by **April 24th, 11:30 AM PDT**, and all delayed date time triggers were executed by **April 27th, 4:00 AM PDT**.

1. 29. April 2026 um 23:09 UTCresolved

   Between April 20th and April 24th, 60% of email and inbox notifications were delayed by at least one hour in EU. Notifications were delayed up to 3 days. Other resource intensive background actions were also impacted at a lesser rate.

2. 30. April 2026 um 00:34 UTCpostmortem

   Starting on **April 20th, 2026 at 10:00 AM PDT**, a combination of scaled-up background action jobs in the EU and a recent change to how date time trigger volume is managed overloaded the system that processes resource intensive background action jobs. This caused multi-hour delays in email and inbox notifications in the EU and prevented date time triggers from executing in all regions. Engineers were first alerted on **April 21st** by our monitoring systems, but did not recognize the full scope of the incident until **April 23rd**. On April 23rd, the change to manage date time trigger volume was reverted and the problematic background action jobs were isolated. All delayed notifications were sent by **April 24th, 11:30 AM PDT**, and all delayed date time triggers were executed by **April 27th, 4:00 AM PDT**.

1. 26. März 2026 um 15:03 UTCinvestigating

   We have received reports that some users are unable to load Asana, especially in and around New York/the East Coast of the US, and have observed intermittent errors. We are investigating this, and will provide an update within an hour.

2. 26. März 2026 um 15:50 UTCmonitoring

   We believe that this was related to http3, and have disabled http3 for the affected CloudFront distribution. We believe Asana should now load after a hard refresh.

3. 26. März 2026 um 18:34 UTCresolved

   This incident has been resolved.

1. 1. März 2026 um 20:31 UTCinvestigating

   Asana remains accessible to customers in the ME region, but we are seeing backends impacted by an AWS ME outage. If that isn't resolved soon, we expect to see some performance degradation and possible outages of the Asana application. This is only for the ME region; other regions are unaffected.

2. 1. März 2026 um 21:03 UTCinvestigating

   We no longer see impact on our servers. We're monitoring, as the AWS incident has not resolved.

3. 2. März 2026 um 09:02 UTCinvestigating

   We are continuing to investigate this issue.

4. 2. März 2026 um 09:05 UTCinvestigating

   We are seeing major impact in the ME region making Asana services unavailable to users whose data is stored in that region. We have taken steps to avoid additional loss of EC2 resources, but are continuing to see high error rates. This cause is AWS incidents affecting the infrastructure (az1 and az3) in the Middle East region: https://health.aws.amazon.com/health/status

5. 2. März 2026 um 10:27 UTCinvestigating

   We are still seeing major impact in the ME region making Asana services unavailable to users whose data is stored in that region. We are continuing to monitor the situation. The cause is AWS incidents affecting the infrastructure in the Middle East region: https://health.aws.amazon.com/health/status

6. 2. März 2026 um 12:03 UTCinvestigating

   We are still seeing major impact in the ME region making Asana services unavailable to users whose data is stored in that region. We are continuing to monitor the situation. The cause is widespread AWS incidents affecting the infrastructure in the Middle East region: https://health.aws.amazon.com/health/status

7. 13. März 2026 um 18:44 UTCmonitoring

   A small number of users were affected by the AWS outage in UAE (me-central-1); following AWS's recommendations, we have moved processing to other regions, and believe there is no user impact.

8. 15. März 2026 um 05:58 UTCresolved

   This incident has been resolved.

1. 5. Februar 2026 um 23:49 UTCmonitoring

   Our primary monitoring is observing an outage for our API and mobile services, but secondary monitoring indicates that API and mobile traffic is operating as usual. Our engineers are reviewing our primary monitoring and will provide updates on the situation.

2. 5. Februar 2026 um 23:58 UTCresolved

   Our engineers have rolled back recent changes to our primary monitoring systems, and our API and mobile systems are fully operational.

1. 26. Januar 2026 um 03:01 UTCinvestigating

   We are investigating an elevated rate of API errors as well as delays reflecting changes for the App in EU.

2. 26. Januar 2026 um 03:19 UTCmonitoring

   We have identified certain expensive workloads and reduced background processing to mitigate this. We see recovery in user facing services and are investigating the expensive workloads; user traffic is now working normally.

3. 26. Januar 2026 um 03:20 UTCmonitoring

   We are continuing to monitor for any further issues.

4. 26. Januar 2026 um 03:29 UTCresolved

   This incident has been resolved.

1. 22. Januar 2026 um 17:48 UTCinvestigating

   We're investigating an outage, it looks like no one is able to reach the Asana webapp.

2. 22. Januar 2026 um 17:51 UTCinvestigating

   We are continuing to investigate this issue.

3. 22. Januar 2026 um 17:59 UTCinvestigating

   We've identified the cause and have rolled back. Based on our monitoring, we should be recovered for some users.

4. 22. Januar 2026 um 18:04 UTCinvestigating

   Error rates have dropped significantly, to about 2%. It's possible some users continue to see errors, but we expect most users to be able to use Asana.

5. 22. Januar 2026 um 18:38 UTCinvestigating

   Our error rates are back to normal baseline, and we don't expect an immediate recurrence. We'll create a post-mortem in the next few days with more details, including what happened and how we plan to prevent this going forward.

6. 22. Januar 2026 um 19:00 UTCresolved

   This incident has been resolved.

7. 27. Januar 2026 um 07:53 UTCpostmortem

   Incident: On 2026-01-22 the Asana App and all associated services had a service disruption due to dependency on a shared database used for storing metadata. This was triggered by a code path which caused overload for that database, followed by request queuing, timeouts, and errors. Impact: From 17:33 - 17:57 UTC the Asana App and all associated services were unavailable. There was a further 14 minutes of partial downtime from 18:45 - 18:59 UTC affecting 10-20% of users, also triggered by dependency on this shared database. Moving forward: We immediately rolled back our application code and added resources for this database. Going forward we will continue to reduce dependency on this shared database for common paths to reduce risk, and monitor for unexpected resource usage. Our metric considers a weighted average of uptime experienced by users at each data center. The number of minutes of downtime shown reflects this weighted average.

1. 6. Januar 2026 um 14:17 UTCresolved

   On January 6th, 2026 at UTC 12:00, we experienced an approximately 50-minute service disruption affecting customers in non-US regions. During this time, some requests may have failed or timed out. What Happened: During routine maintenance, we upgraded a core infrastructure component. While the upgrade itself completed as expected, some services did not successfully reconnect to the updated infrastructure. This led to temporary communication issues and degraded service in the affected regions. We apologize for the inconvenience and want to assure you that we are taking steps to help prevent similar issues in the future.

1. 5. Januar 2026 um 21:17 UTCinvestigating

   Users are currently unable to begin new sessions in the Asana web app. Our engineers are working to investigate and mitigate this issue as soon as possible. Existing web sessions are unaffected, along with mobile and API traffic.

2. 5. Januar 2026 um 21:29 UTCmonitoring

   Our engineers have identified and reverted the change preventing users from starting new Asana web app sessions. We're monitoring the situation to ensure recovery. The Asana web app is operational, and other services (mobile, API) are unaffected.

3. 5. Januar 2026 um 21:50 UTCresolved

   Thank you for your patience. Service is fully restored, and the Asana web app is back to normal functionality.

1. 24. November 2025 um 20:28 UTCresolved

   Resolved - We have fully resolved an incident related to a product permissions bug that briefly impacted some of our customers between November 18 and November 19. This issue was contained entirely within customer domains and did not expose any data externally.