Histórico de interrupções do Asana

1. 23 Here 2026 da 23:57 UTCinvestigating

   Temos uma degradação significativa em nosso sistema para processamento de trabalho assíncrono. Nós anteriormente tivemos algumas falhas de usuários de aplicativos web, mas isso parece ter resolvido. Estamos a monitorizar o trabalho assíncrono.

2. 24 Here 2026 da 00:03 UTCmonitoring

   Pausamos algumas cargas de trabalho problemáticas, e achamos que estamos vendo recuperação.

3. 24 Here 2026 da 02:35 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Here 2026 da 15:33 UTCidentified

   Os serviços Asana estão atualmente passando por uma grande perturbação do serviço. Identificamos uma causa provável e estamos trabalhando em aplicar uma correção. Isto afecta todos os serviços e todas as regiões.

2. 21 Here 2026 da 15:51 UTCidentified

   Identificámos a causa desta interrupção e iniciámos alterações para resolver este problema. Estamos a ver sinais de recuperação, e vamos publicar uma actualização assim que confirmarmos a recuperação.

3. 21 Here 2026 da 16:08 UTCidentified

   Continuamos trabalhando em uma solução para esse problema.

4. 21 Here 2026 da 16:10 UTCresolved

   A correção foi aplicada. Observamos a recuperação das taxas de erro e do tráfego, e acreditamos que este incidente está agora resolvido. Publicaremos uma autópsia em 72 horas.

5. 24 Here 2026 da 00:22 UTCpostmortem

   **Incidente: ** Uma atualização de infraestrutura visando segurança fez com que o DynamoDB se tornasse inacessível em todo o ambiente de produção da Asana. Essa mudança foi relacionada a uma iniciativa de isolamento de produção, e foi aplicada de uma forma que deixou todos os nossos serviços de produção incapazes de usar tabelas DynamoDB que usamos para metadados e tráfego de roteamento. Uma vez que a mudança foi revertida nossos serviços retornaram às operações normais. **Impacto:** Os serviços de Asana estavam completamente indisponíveis por aproximadamente 30 minutos, 2026-10-21 15:21 UTC-15:51 UTC, e na sua maioria indisponível por mais 20 minutos, incluindo 15:05 UTC-15:55 UTC. Isto também causou atraso para as ações de base durante o período de impacto; recuperação após o final do incidente concluído até 16:00 UTC. ** Avançando:** Estamos atualizando o processo de implantação para capturar essa classe de erro. Estamos nos movendo para um sistema de isolamento que permite um lançamento mais gradual de mudanças semelhantes, permitindo-nos detectar a configuração incorreta em testes pré-produção. Nossa métrica considera uma média ponderada de tempo de atividade vivenciada pelos usuários em cada data center. O número de minutos de inatividade apresentados reflete esta média ponderada.

Traduzido automaticamente da atualização oficial do incidente.

1. 30 Gwengolo 2026 da 14:31 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 30 Gwengolo 2026 da 15:09 UTCidentified

   Estamos actualmente a assistir à recuperação do sistema e a acompanhar activamente a situação para garantir uma recuperação completa.

3. 30 Gwengolo 2026 da 15:21 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 29 Gwengolo 2026 da 12:14 UTCinvestigating

   No momento, estamos investigando o problema.

2. 29 Gwengolo 2026 da 15:25 UTCresolved

   O incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 21 Gwengolo 2026 da 14:59 UTCidentified

   Ouvimos relatos de regras e automações que não funcionam na região da UE. Identificámos a fonte do problema e corrigimo-lo para novos gatilhos de automações. Nossos engenheiros estão atualmente trabalhando no backlog de automação que desencadeou e não foi executado durante o incidente.

2. 21 Gwengolo 2026 da 15:00 UTCidentified

   Continuamos trabalhando em uma solução para esse problema.

3. 21 Gwengolo 2026 da 15:39 UTCmonitoring

   Estamos a trabalhar no nosso caminho através do histórico de automações que não foram executadas.

4. 21 Gwengolo 2026 da 16:10 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 17 Gwengolo 2026 da 14:36 UTCinvestigating

   Recebemos um alerta para desempenho lento incomum em várias regiões. Estamos a investigar.

2. 17 Gwengolo 2026 da 15:12 UTCinvestigating

   Continuamos a investigar esta questão.

3. 17 Gwengolo 2026 da 15:13 UTCresolved

   Este incidente foi resolvido.

Traduzido automaticamente da atualização oficial do incidente.

1. 2 Gwengolo 2026 da 18:08 UTCinvestigating

   Estamos actualmente a investigar esta questão.

2. 2 Gwengolo 2026 da 18:13 UTCinvestigating

   Continuamos a investigar esta questão.

3. 2 Gwengolo 2026 da 18:14 UTCinvestigating

   O retrocesso parece ter resolvido completamente os erros. Estamos a monitorizar de perto, mas os utilizadores devem poder aceder novamente à Asana.

4. 2 Gwengolo 2026 da 18:14 UTCmonitoring

   Foi implementada uma correção e estamos monitorando os resultados.

5. 2 Gwengolo 2026 da 18:49 UTCresolved

   Este incidente foi resolvido.

6. 4 Gwengolo 2026 da 19:52 UTCpostmortem

   Incidente: Um sistema interno responsável por escalar automaticamente a capacidade do servidor de infraestrutura em um de nossos clusters de computação parou de substituir a capacidade que tinha sido ciclada durante a manutenção de rotina. Isto causou uma redução gradual da capacidade disponível durante várias horas. Uma posterior implantação foi ativada com capacidade insuficiente, fazendo com que todos os novos pedidos para que o cluster de computação falhar. Para mitigar o impacto, voltamos a uma revisão de lançamento anterior, que ainda tinha capacidade suficiente. Impacto: Durante aproximadamente 30 minutos, os clientes cujo tráfego foi tratado por este cluster de computação viram o tempo de inatividade total; outros clientes não foram afetados. Nenhum dado do cliente foi perdido. Avançando: Adicionamos monitoramento adicional para detectar este tipo de falha de escala de capacidade muito antes, e adicionamos salvaguardas para evitar que as implantações mudem o tráfego antes que seja confirmada capacidade saudável suficiente. Nossa métrica considera uma média ponderada de tempo de trabalho experimentado pelos usuários em cada data center. O número de minutos de inatividade apresentados reflete esta média ponderada.

Traduzido automaticamente da atualização oficial do incidente.

1. 31 Eost 2026 da 15:14 UTCinvestigating

   Estamos investigando alertas para erros de desempenho e aplicação lentos.

2. 31 Eost 2026 da 15:55 UTCinvestigating

   Continuamos a investigar a questão; revertemos as mudanças recentes, e estamos trabalhando para identificar a fonte dos erros.

3. 31 Eost 2026 da 16:24 UTCinvestigating

   Fizemos alterações de configuração e vemos recuperação parcial, mas continuamos a ver alguns erros elevados.

4. 31 Eost 2026 da 16:47 UTCmonitoring

   Aplicámos uma solução, estamos a ver sinais de recuperação.

5. 31 Eost 2026 da 17:18 UTCresolved

   Os sintomas de face do utilizador recuperaram. Continuaremos a monitorar, e priorizaremos uma retrospectiva para entender e prevenir incidentes semelhantes no futuro.

6. 2 Gwengolo 2026 da 21:29 UTCpostmortem

   Temos trabalhado para adicionar uma camada de cache ao nosso oleoduto de atualização, afinando-o cuidadosamente e rolando-o gradualmente. Na quarta-feira, 26 de agosto, habilitamos para a maioria dos casos de uso e inicialmente foi bem sucedido. Na segunda-feira, 31 de agosto, uma combinação de mudanças de infraestrutura não relacionadas e pico de tráfego empurrou o cache para além de seus limites de escala. Uma vez que esse limiar foi cruzado, o cache tornou-se inutilizável, e muitos pods servindo o tráfego de leitura para o aplicativo Asana não poderia mais servi-lo. Nós mitigamos o incidente revertendo o sistema para usar o caminho de código anterior, não-cached. O retorno foi bem sucedido, mas a recuperação levou mais tempo do que esperávamos para esta classe de questão. Está em curso uma análise mais completa. Vamos acompanhar com causas raiz, itens de ação, e melhorias, incluindo por que a recuperação levou tanto tempo quanto fez. Ficamos totalmente para baixo por cerca de 25% dos nossos usuários, por 2 horas, 15 minutos.

Traduzido automaticamente da atualização oficial do incidente.

1. 6 Eost 2026 da 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 Gouere 2026 da 18:49 UTCidentified

   Estamos vendo erros por parte (cerca de 10%) dos usuários nos EUA para o Asana webapp. Identificámos a causa raiz e estamos a trabalhar na identificação de uma resolução.

2. 7 Gouere 2026 da 19:12 UTCmonitoring

   Implementámos uma mitigação e estamos a monitorizar para garantir a recuperação.

3. 7 Gouere 2026 da 19:21 UTCmonitoring

   Continuamos monitorando quaisquer outros problemas.

4. 7 Gouere 2026 da 19:24 UTCresolved

   Este incidente foi resolvido.

5. 8 Gouere 2026 da 21:28 UTCpostmortem

   **Incidente**: Uma mudança de configuração removeu inadvertidamente um recurso crítico exigido por um de nossos serviços. Embora as infra-estruturas existentes continuassem a funcionar normalmente, as novas infra-estruturas em escala não podiam ficar prontas. À medida que o tráfego matinal aumentava, havia uma lacuna crescente entre as solicitações recebidas e a capacidade do nosso sistema de lidar com elas, resultando em degradação do serviço. Resolvemos o problema restaurando manualmente o recurso em falta e corrigindo a alteração de configuração que causou sua remoção. □ **Impacto**: Por aproximadamente 1,5 horas, um subconjunto de clientes experimentou uma interrupção total de nossos aplicativos web e aplicativos desktop. Durante esse tempo, os usuários afetados não conseguiram acessar Asana. Nenhum dado do cliente foi perdido. □ ** Avançando**: Estamos implementando salvaguardas adicionais em nosso processo de gerenciamento de configuração para evitar que recursos críticos sejam removidos inadvertidamente. Também estamos aprimorando nossos sistemas de monitoramento para detectar a degradação mais cedo, antes de impactar o acesso do cliente. □ Nossa métrica considera uma média ponderada de tempo de atividade vivenciada pelos usuários em cada data center. O número de minutos de inatividade apresentados reflete esta média ponderada.

Traduzido automaticamente da atualização oficial do incidente.

1. 29 Ebrel 2026 da 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 Ebrel 2026 da 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 Ebrel 2026 da 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 Ebrel 2026 da 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 Meurzh 2026 da 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 Meurzh 2026 da 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 Meurzh 2026 da 18:34 UTCresolved

   This incident has been resolved.

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

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

3. 2 Meurzh 2026 da 09:02 UTCinvestigating

   We are continuing to investigate this issue.

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

   This incident has been resolved.

1. 5 Cʼhwevrer 2026 da 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 Cʼhwevrer 2026 da 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 Genver 2026 da 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 Genver 2026 da 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 Genver 2026 da 03:20 UTCmonitoring

   We are continuing to monitor for any further issues.

4. 26 Genver 2026 da 03:29 UTCresolved

   This incident has been resolved.

1. 22 Genver 2026 da 17:48 UTCinvestigating

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

2. 22 Genver 2026 da 17:51 UTCinvestigating

   We are continuing to investigate this issue.

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

   This incident has been resolved.

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

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

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