Historia awarii Asana

1. 23 października 2026 23:57 UTCinvestigating

   Mamy w naszym systemie znaczną degradację do przetwarzania pracy asynchronicznej. Mieliśmy wcześniej kilka awarii od użytkowników aplikacji web, ale to wydaje się rozwiązać. Monitorujemy pracę asynchroniczną.

2. 24 października 2026 00:03 UTCmonitoring

   Zatrzymaliśmy kilka problematycznych prac, i myślimy, że widzimy powrót do zdrowia.

3. 24 października 2026 02:35 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 października 2026 15:33 UTCidentified

   Usługi Asana doświadczają obecnie poważnych zakłóceń w świadczeniu usług. Zidentyfikowaliśmy prawdopodobną przyczynę i pracujemy nad tym. Dotyczy to wszystkich usług i wszystkich regionów.

2. 21 października 2026 15:51 UTCidentified

   Zidentyfikowaliśmy przyczynę tego przestoju i wprowadziliśmy zmiany w celu rozwiązania tego problemu. Widzimy oznaki powrotu do zdrowia, i opublikujemy aktualizację, gdy potwierdzimy powrót do zdrowia.

3. 21 października 2026 16:08 UTCidentified

   Kontynuujemy prace nad rozwiązaniem tego problemu.

4. 21 października 2026 16:10 UTCresolved

   Naprawiono. Obserwowaliśmy poprawę wskaźnika błędów i ruchu, i uważamy, że ten incydent został rozwiązany. W ciągu 72 godzin wykonamy sekcję zwłok.

5. 24 października 2026 00:22 UTCpostmortem

   / Incydent: Aktualizacja infrastruktury ukierunkowana na bezpieczeństwo spowodowała, że DynamiodB stał się niedostępny w całym środowisku produkcyjnym Asany. Ta zmiana była związana z inicjatywą izolacji produkcji i była stosowana w taki sposób, że wszystkie nasze usługi produkcyjne nie mogły korzystać z tabel DynamiodB, które używamy do metadanych i ruchu routingu. Po zmianie nasze usługi wróciły do normalnych operacji. * * Uderzenie: * * Usługi Asana były całkowicie niedostępne przez około 30 minut, 2026- 10- 21 15: 21 UTC- 15: 51 UTC i głównie niedostępne przez kolejne 20 minut, w tym 15: 05 UTC- 15: 55 UTC. Spowodowało to również opóźnienie działań w tle w okresie oddziaływania; odzyskanie po zakończeniu incydentu zakończonego przed 16: 00 UTC. * * Moving forward: * * Aktualizujemy proces rozmieszczania w celu złapania tej klasy błędów. Przeniesiemy się do systemu izolacji, który umożliwi bardziej stopniowe wprowadzanie podobnych zmian, co pozwoli nam wykryć błędne konfiguracje w testach przedprodukcyjnych. Nasza metryka uwzględnia średnią ważoną czasu przestoju, jakiego doświadczają użytkownicy w każdym centrum danych. Liczba minut przestoju odzwierciedla tę średnią ważoną.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 30 września 2026 14:31 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 30 września 2026 15:09 UTCidentified

   Obecnie obserwujemy ożywienie systemu i aktywnie monitorujemy sytuację, aby zapewnić pełne ożywienie.

3. 30 września 2026 15:21 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 29 września 2026 12:14 UTCinvestigating

   Obecnie badamy ten problem.

2. 29 września 2026 15:25 UTCresolved

   Incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 września 2026 14:59 UTCidentified

   Słyszeliśmy raporty o przepisach i automatach niedziałających w regionie UE. Zidentyfikowaliśmy źródło problemu i naprawiliśmy go dla nowych automatów. Nasi inżynierowie pracują obecnie nad zaległością automatyzacji, która została uruchomiona i nie działała podczas incydentu.

2. 21 września 2026 15:00 UTCidentified

   Kontynuujemy prace nad rozwiązaniem tego problemu.

3. 21 września 2026 15:39 UTCmonitoring

   Obecnie pracujemy nad zaległością automatów, które nie działały.

4. 21 września 2026 16:10 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 17 września 2026 14:36 UTCinvestigating

   Otrzymaliśmy ostrzeżenie o niezwykłym powolnym występie w kilku regionach. Prowadzimy śledztwo.

2. 17 września 2026 15:12 UTCinvestigating

   Nadal badamy tę kwestię.

3. 17 września 2026 15:13 UTCresolved

   Ten incydent został rozwiązany.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 2 września 2026 18:08 UTCinvestigating

   Obecnie badamy tę kwestię.

2. 2 września 2026 18:13 UTCinvestigating

   Nadal badamy tę kwestię.

3. 2 września 2026 18:14 UTCinvestigating

   Rollback wydaje się mieć całkowicie rozwiązane błędy. Monitorujemy dokładnie, ale użytkownicy powinni mieć dostęp do Asany.

4. 2 września 2026 18:14 UTCmonitoring

   Wprowadzono rozwiązanie i monitorujemy wyniki.

5. 2 września 2026 18:49 UTCresolved

   Ten incydent został rozwiązany.

6. 4 września 2026 19:52 UTCpostmortem

   Incydent: Wewnętrzny system odpowiedzialny za automatyczne skalowanie pojemności serwera backend w jednym z naszych klastrów obliczeniowych przestał zastępować pojemność, która została przerwana podczas rutynowej konserwacji. Spowodowało to stopniowe zmniejszenie dostępnej przepustowości w ciągu kilku godzin. Kolejne uruchomienie zostało uruchomione z niewystarczającą przepustowością, co spowodowało, że wszystkie nowe wnioski dotyczące niepowodzenia obliczeń tego klastra. Aby złagodzić ten wpływ, powróciliśmy do poprzedniego przeglądu wydania, który nadal miał wystarczające możliwości. Impact: Przez około 30 minut klienci, których ruch był obsługiwany przez ten klaster obliczeń widział pełne przestoje; inni klienci nie zostały naruszone. Nie utracono danych klientów. Dalsze działania: Dodaliśmy dodatkowy monitoring w celu wykrycia tego rodzaju awarii skalowania pojemności znacznie wcześniej oraz dodaliśmy zabezpieczenia zapobiegające przemieszczaniu ruchu, zanim zostanie potwierdzona wystarczająca sprawność. _ Nasza metryka uwzględnia średnią ważoną czasu przestoju doświadczonego przez użytkowników w każdym centrum danych. Liczba minut przestoju odzwierciedla tę średnią ważoną. _

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 31 sierpnia 2026 15:14 UTCinvestigating

   Prowadzimy śledztwo w sprawie ostrzeżeń o powolnych błędach wydajności i aplikacji.

2. 31 sierpnia 2026 15:55 UTCinvestigating

   Kontynuujemy badanie tej kwestii; odwróciliśmy ostatnie zmiany i pracujemy nad zidentyfikowaniem źródła błędów.

3. 31 sierpnia 2026 16:24 UTCinvestigating

   Dokonaliśmy zmian konfiguracji i widzimy częściową regenerację, ale nadal widzimy pewne podwyższone błędy.

4. 31 sierpnia 2026 16:47 UTCmonitoring

   Zastosowaliśmy opatrunek.

5. 31 sierpnia 2026 17:18 UTCresolved

   Objawy ze strony użytkownika ustąpiły. Będziemy nadal monitorować i traktować priorytetowo retrospektywę, aby zrozumieć i zapobiec podobnym incydentom w przyszłości.

6. 2 września 2026 21:29 UTCpostmortem

   Pracowaliśmy nad dodaniem warstwy buforowej do naszego rurociągu aktualizacji, dostrojeniem go ostrożnie i stopniowym toczeniem. W środę, 26 sierpnia włączyliśmy go do większości przypadków użycia, i początkowo dobrze się sprawdził. W poniedziałek, 31 sierpnia, połączenie niepowiązanych zmian w infrastrukturze i ruch szczytowy pchnął cache poza swoje ograniczenia skalowania. Po przekroczeniu tego progu, cache stało się bezużyteczne, a wiele kapsuł obsługujących ruch odczytu dla aplikacji Asana nie mógł już służyć. Złagodziliśmy ten incydent cofając system, aby użyć poprzedniej, niebuforowanej ścieżki kodu. Zwrot był udany, ale ożywienie zajęło więcej czasu, niż się spodziewaliśmy w tej klasie problemów. Trwa pełniejsza analiza. Będziemy kontynuować działania związane z podstawowymi przyczynami, działaniami i ulepszeniami, w tym z tym, dlaczego ożywienie trwało tak długo, jak trwało. Byliśmy całkowicie w dół dla około 25% naszych użytkowników, na 2 godziny, 15 minut.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 sierpnia 2026 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 lipca 2026 18:49 UTCidentified

   Widzimy błędy dla części (około 10%) użytkowników w USA dla webapp Asana. Zidentyfikowaliśmy przyczynę i pracujemy nad określeniem rozwiązania.

2. 7 lipca 2026 19:12 UTCmonitoring

   Wprowadziliśmy środki łagodzące i monitorujemy, aby zapewnić ożywienie gospodarcze.

3. 7 lipca 2026 19:21 UTCmonitoring

   Nadal monitorujemy wszelkie dalsze problemy.

4. 7 lipca 2026 19:24 UTCresolved

   Ten incydent został rozwiązany.

5. 8 lipca 2026 21:28 UTCpostmortem

   * * Incydent * * Zmiana konfiguracji nieumyślnie usunęła krytyczny zasób wymagany przez jedną z naszych usług. Podczas gdy istniejąca infrastruktura nadal normalnie funkcjonowała, nowo skalowana infrastruktura nie mogła stać się gotowa. Wraz ze wzrostem natężenia ruchu w godzinach porannych pojawiała się coraz większa luka między wnioskami przychodzącymi a zdolnością naszego systemu do ich obsługi, co doprowadziło do degradacji usług. Rozwiązaliśmy problem ręcznie przywracając brakujące zasoby i poprawiając zmianę konfiguracji, która spowodowała jego usunięcie. Uzasadnienie * * Uderzenie * *: Przez około 1,5 godziny podzbiory klientów doświadczyły całkowitego wyczerpania aplikacji internetowych i aplikacji na pulpicie. W tym czasie dotknięci użytkownicy nie byli w stanie uzyskać dostępu do Asana. Nie utracono danych klientów. Uzasadnienie * * Moving forward * *: Wprowadzamy dodatkowe zabezpieczenia w procesie zarządzania konfiguracją, aby zapobiec przypadkowemu usuwaniu krytycznych zasobów. Ulepszamy również nasze systemy monitorowania w celu wcześniejszego wykrycia degradacji, zanim wpłynie to na dostęp klientów. Uzasadnienie Nasza metryka uwzględnia średnią ważoną czasu przestoju, jakiego doświadczają użytkownicy w każdym centrum danych. Liczba minut przestoju odzwierciedla tę średnią ważoną.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 29 kwietnia 2026 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 kwietnia 2026 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 kwietnia 2026 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 kwietnia 2026 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 marca 2026 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 marca 2026 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 marca 2026 18:34 UTCresolved

   This incident has been resolved.

1. 1 marca 2026 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 marca 2026 21:03 UTCinvestigating

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

3. 2 marca 2026 09:02 UTCinvestigating

   We are continuing to investigate this issue.

4. 2 marca 2026 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 marca 2026 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 marca 2026 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 marca 2026 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 marca 2026 05:58 UTCresolved

   This incident has been resolved.

1. 5 lutego 2026 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 lutego 2026 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 stycznia 2026 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 stycznia 2026 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 stycznia 2026 03:20 UTCmonitoring

   We are continuing to monitor for any further issues.

4. 26 stycznia 2026 03:29 UTCresolved

   This incident has been resolved.

1. 22 stycznia 2026 17:48 UTCinvestigating

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

2. 22 stycznia 2026 17:51 UTCinvestigating

   We are continuing to investigate this issue.

3. 22 stycznia 2026 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 stycznia 2026 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 stycznia 2026 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 stycznia 2026 19:00 UTCresolved

   This incident has been resolved.

7. 27 stycznia 2026 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 stycznia 2026 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 stycznia 2026 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 stycznia 2026 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 stycznia 2026 21:50 UTCresolved

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

1. 24 listopada 2025 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.