История сбоев Asana

1. 23 октября 2026 г. в 23:57 UTCinvestigating

   В нашей системе обработки асинхронной работы наблюдается значительная деградация. Ранее у нас были некоторые сбои с пользователями веб-приложений, но, похоже, это было решено. Мы отслеживаем асинхронную работу.

2. 24 октября 2026 г. в 00:03 UTCmonitoring

   Мы приостановили некоторые проблемные рабочие нагрузки, и мы думаем, что видим восстановление.

3. 24 октября 2026 г. в 02:35 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 21 октября 2026 г. в 15:33 UTCidentified

   В настоящее время службы Asana испытывают серьезные перебои в обслуживании. Мы определили вероятную причину и работаем над применением исправления. Это касается всех служб и всех регионов.

2. 21 октября 2026 г. в 15:51 UTCidentified

   Мы определили причину этого отключения и инициировали изменения для решения этой проблемы. Мы видим некоторые признаки восстановления и опубликуем обновление, как только подтвердим восстановление.

3. 21 октября 2026 г. в 16:08 UTCidentified

   Мы продолжаем работать над решением этой проблемы.

4. 21 октября 2026 г. в 16:10 UTCresolved

   Применяется исправление. Мы наблюдали восстановление частоты ошибок и трафика, и считаем, что этот инцидент теперь разрешен. Мы опубликуем вскрытие в течение 72 часов.

5. 24 октября 2026 г. в 00:22 UTCpostmortem

   ** Инцидент:** Обновление инфраструктуры, нацеленное на безопасность, привело к тому, что DynamoDB стал недоступным в производственной среде Asana. Это изменение было связано с инициативой по изоляции производства и было применено таким образом, что все наши производственные службы не могли использовать таблицы DynamoDB, которые мы используем для метаданных и маршрутизации трафика. Как только изменения были возвращены, наши услуги вернулись к нормальной работе. ** Воздействие:** Услуги Asana были полностью недоступны в течение примерно 30 минут, 2026-10-21 15:21 UTC-15:51 UTC и в основном недоступны в течение следующих 20 минут, включая 15:05 UTC-15:55 UTC. Это также привело к задержке фоновых действий в течение периода воздействия; восстановление после окончания инцидента завершено к 16:00 UTC. ** Двигаясь вперед:** Мы обновляем процесс развертывания, чтобы поймать этот класс ошибок. Мы перейдем к изоляционной системе, которая позволяет более постепенно внедрять аналогичные изменения, что позволяет нам обнаруживать неправильную конфигурацию в предварительном тестировании. Наша метрика учитывает средневзвешенное время безотказной работы, которое испытывают пользователи в каждом центре обработки данных. Количество минут простоя отражает эту средневзвешенную величину.

Автоматический перевод официального обновления инцидента.

1. 30 сентября 2026 г. в 14:31 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 30 сентября 2026 г. в 15:09 UTCidentified

   В настоящее время мы наблюдаем восстановление системы и активно отслеживаем ситуацию, чтобы обеспечить полное восстановление.

3. 30 сентября 2026 г. в 15:21 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 29 сентября 2026 г. в 12:14 UTCinvestigating

   В настоящее время мы изучаем этот вопрос.

2. 29 сентября 2026 г. в 15:25 UTCresolved

   Инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 21 сентября 2026 г. в 14:59 UTCidentified

   Мы слышали сообщения о правилах и автоматизации, которые не работают в регионе ЕС. Мы определили источник проблемы и исправили его для новых триггеров автоматизации. Наши инженеры в настоящее время работают над отставанием автоматизации, которая сработала и не работала во время инцидента.

2. 21 сентября 2026 г. в 15:00 UTCidentified

   Мы продолжаем работать над решением этой проблемы.

3. 21 сентября 2026 г. в 15:39 UTCmonitoring

   В настоящее время мы прокладываем путь через отставание автоматизации, которая не работала.

4. 21 сентября 2026 г. в 16:10 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 17 сентября 2026 г. в 14:36 UTCinvestigating

   Мы получили предупреждение о необычной медленной производительности в нескольких регионах. Мы расследуем.

2. 17 сентября 2026 г. в 15:12 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 17 сентября 2026 г. в 15:13 UTCresolved

   Этот инцидент был урегулирован.

Автоматический перевод официального обновления инцидента.

1. 2 сентября 2026 г. в 18:08 UTCinvestigating

   В настоящее время мы расследуем этот вопрос.

2. 2 сентября 2026 г. в 18:13 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 2 сентября 2026 г. в 18:14 UTCinvestigating

   Откат, кажется, полностью устранил ошибки. Мы внимательно следим, но пользователи должны снова получить доступ к Asana.

4. 2 сентября 2026 г. в 18:14 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

5. 2 сентября 2026 г. в 18:49 UTCresolved

   Этот инцидент был урегулирован.

6. 4 сентября 2026 г. в 19:52 UTCpostmortem

   Внутренняя система, ответственная за автоматическое увеличение пропускной способности сервера в одном из наших вычислительных кластеров, перестала заменять пропускную способность, которая была отключена во время текущего обслуживания. Это привело к постепенному сокращению имеющихся мощностей в течение нескольких часов. Последующее развертывание было активировано с недостаточным потенциалом, что привело к сбою всех новых запросов на этот вычислительный кластер. Чтобы смягчить последствия, мы вернулись к предыдущему пересмотру релиза, который все еще имел достаточную емкость. В течение примерно 30 минут клиенты, чей трафик обрабатывался этим вычислительным кластером, видели полное время простоя. Данные клиентов не были потеряны. Мы добавили дополнительный мониторинг, чтобы обнаружить этот тип сбоя масштабирования пропускной способности гораздо раньше, и добавили меры предосторожности, чтобы предотвратить перемещение трафика до подтверждения достаточной здоровой пропускной способности. Наша метрика учитывает средневзвешенное время безотказной работы, которое испытывают пользователи в каждом центре обработки данных. Количество минут простоя отражает эту средневзвешенную величину

Автоматический перевод официального обновления инцидента.

1. 31 августа 2026 г. в 15:14 UTCinvestigating

   Мы изучаем оповещения о медленной производительности и ошибках приложений.

2. 31 августа 2026 г. в 15:55 UTCinvestigating

   Мы продолжаем исследовать этот вопрос, мы вернулись к последним изменениям и работаем над выявлением источника ошибок.

3. 31 августа 2026 г. в 16:24 UTCinvestigating

   Мы внесли изменения в конфигурацию и видим частичное восстановление, но мы продолжаем видеть некоторые повышенные ошибки.

4. 31 августа 2026 г. в 16:47 UTCmonitoring

   Мы применили исправление и видим признаки восстановления.

5. 31 августа 2026 г. в 17:18 UTCresolved

   Симптомы, связанные с пользователем, восстановились. Мы продолжим мониторинг и будем уделять приоритетное внимание ретроспективе, чтобы понять и предотвратить подобные инциденты в будущем.

6. 2 сентября 2026 г. в 21:29 UTCpostmortem

   Мы работали над тем, чтобы добавить слой кэширования в наш конвейер обновления, тщательно настраивая его и постепенно разворачивая. В среду, 26 августа, мы включили его для большинства случаев использования, и он изначально работал хорошо. В понедельник, 31 августа, сочетание несвязанных изменений инфраструктуры и пикового трафика выдвинуло кэш за пределы масштабирования. Как только этот порог был пересечен, кэш стал непригодным для использования, и многие контейнеры, обслуживающие трафик чтения для приложения Asana, больше не могли его обслуживать. Мы смягчили инцидент, вернув систему, чтобы использовать предыдущий, не кэшированный путь кода. Возвращение было успешным, но восстановление заняло больше времени, чем мы ожидали. Сейчас проводится более полный анализ. Мы будем следить за первопричинами, элементами действия и улучшениями, в том числе за тем, почему восстановление заняло столько времени, сколько это было. Мы полностью потеряли около 25% наших пользователей в течение 2 часов 15 минут.

Автоматический перевод официального обновления инцидента.

1. 6 августа 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 июля 2026 г. в 18:49 UTCidentified

   Мы видим ошибки для части (около 10%) пользователей в США для веб-приложения Asana. Мы определили первопричину и работаем над определением решения.

2. 7 июля 2026 г. в 19:12 UTCmonitoring

   Мы внедрили меры по смягчению последствий и осуществляем мониторинг для обеспечения восстановления.

3. 7 июля 2026 г. в 19:21 UTCmonitoring

   Мы продолжаем отслеживать любые дополнительные проблемы.

4. 7 июля 2026 г. в 19:24 UTCresolved

   Этот инцидент был урегулирован.

5. 8 июля 2026 г. в 21:28 UTCpostmortem

   ** Инцидент**: Изменение конфигурации непреднамеренно устранило критический ресурс, необходимый одной из наших служб. Хотя существующая инфраструктура продолжает функционировать в нормальном режиме, новая масштабируемая инфраструктура не может быть готова. По мере увеличения утреннего трафика увеличивался разрыв между поступающими запросами и способностью нашей системы обрабатывать их, что приводило к ухудшению обслуживания. Мы решили проблему, вручную восстановив недостающий ресурс и исправив изменение конфигурации, вызвавшее его удаление. ** Воздействие**: В течение примерно 1,5 часов подгруппа клиентов испытывала полное отключение нашего веб-приложения и настольных приложений. За это время пострадавшие пользователи не смогли получить доступ к Asana. Данные клиентов не были потеряны. ** Двигаемся вперед**: Мы внедряем дополнительные меры безопасности в процесс управления конфигурацией, чтобы предотвратить непреднамеренное удаление критически важных ресурсов. Мы также совершенствуем наши системы мониторинга для обнаружения деградации раньше, прежде чем это повлияет на доступ клиентов. Наша метрика учитывает средневзвешенное время безотказной работы, которое испытывают пользователи в каждом центре обработки данных. Количество минут простоя отражает эту средневзвешенную величину.

Автоматический перевод официального обновления инцидента.

1. 29 апреля 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 апреля 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 апреля 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 апреля 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 марта 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 марта 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 марта 2026 г. в 18:34 UTCresolved

   This incident has been resolved.

1. 1 марта 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 марта 2026 г. в 21:03 UTCinvestigating

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

3. 2 марта 2026 г. в 09:02 UTCinvestigating

   We are continuing to investigate this issue.

4. 2 марта 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 марта 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 марта 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 марта 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 марта 2026 г. в 05:58 UTCresolved

   This incident has been resolved.

1. 5 февраля 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 февраля 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 января 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 января 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 января 2026 г. в 03:20 UTCmonitoring

   We are continuing to monitor for any further issues.

4. 26 января 2026 г. в 03:29 UTCresolved

   This incident has been resolved.

1. 22 января 2026 г. в 17:48 UTCinvestigating

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

2. 22 января 2026 г. в 17:51 UTCinvestigating

   We are continuing to investigate this issue.

3. 22 января 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 января 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 января 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 января 2026 г. в 19:00 UTCresolved

   This incident has been resolved.

7. 27 января 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 января 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 января 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 января 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 января 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 ноября 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.