Historique des pannes de Asana

1. 23 octobre 2026 à 23:57 UTCinvestigating

   Nous avons une dégradation importante dans notre système de traitement des travaux asynchrones. Nous avons précédemment eu quelques pannes des utilisateurs d'applications Web, mais cela semble avoir résolu. Nous surveillons le travail asynchrone.

2. 24 octobre 2026 à 00:03 UTCmonitoring

   Nous avons interrompu certaines tâches problématiques, et nous pensons que nous voyons la reprise.

3. 24 octobre 2026 à 02:35 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 octobre 2026 à 15:33 UTCidentified

   Les services d'Asana connaissent actuellement une perturbation majeure. Nous avons identifié une cause probable et nous travaillons à appliquer une correction. Cela touche tous les services et toutes les régions.

2. 21 octobre 2026 à 15:51 UTCidentified

   Nous avons identifié la cause de cette panne et nous avons entrepris des changements pour y remédier. Nous voyons des signes de récupération, et afficherons une mise à jour une fois que nous aurons confirmé la récupération.

3. 21 octobre 2026 à 16:08 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

4. 21 octobre 2026 à 16:10 UTCresolved

   La correction a été appliquée. Nous avons observé la récupération des taux d'erreur et du trafic, et croyons que cet incident est maintenant résolu. Nous publierons un postmortem/RCA dans les 72 heures.

5. 24 octobre 2026 à 00:22 UTCpostmortem

   **Incident :** Une mise à jour de l'infrastructure ciblant la sécurité a rendu DynamoDB inaccessible à travers l'environnement de production d'Asana. Ce changement était lié à une initiative d'isolement de la production et a été appliqué d'une manière qui a empêché tous nos services de production d'utiliser les tables DynamoDB que nous utilisons pour les métadonnées et le trafic de routage. Une fois que le changement a été retourné nos services retournés à des opérations normales. **Impact:** Les services Asana étaient complètement indisponibles pendant environ 30 minutes, 2026-10-21 15:21 UTC-15:51 UTC, et la plupart étaient indisponibles pendant 20 minutes supplémentaires, dont 15:05 UTC-15:55 UTC. Cela a également causé un retard pour les actions de fond pendant la période d'impact; rétablissement après la fin de l'incident terminé par 16:00 UTC. **Avancer:** Nous mettons à jour le processus de déploiement pour attraper cette classe d'erreurs. Nous allons passer à un système d'isolement qui permet un déploiement plus progressif de changements similaires, nous permettant de détecter les erreurs de configuration dans les tests de préproduction. Notre métrique considère une moyenne pondérée de temps d'arrêt vécu par les utilisateurs dans chaque centre de données. Le nombre de minutes d'arrêt indiqué reflète cette moyenne pondérée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 30 septembre 2026 à 14:31 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 30 septembre 2026 à 15:09 UTCidentified

   Nous assistons actuellement au rétablissement du système et nous suivons activement la situation pour assurer un rétablissement complet.

3. 30 septembre 2026 à 15:21 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 29 septembre 2026 à 12:14 UTCinvestigating

   Nous étudions actuellement le problème.

2. 29 septembre 2026 à 15:25 UTCresolved

   L'incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 septembre 2026 à 14:59 UTCidentified

   Nous avons entendu des rapports de règles et d'automatisation qui ne sont pas en cours dans la région de l'UE. Nous avons identifié la source du problème et l'avons corrigé pour les nouveaux déclencheurs d'automatisation. Nos ingénieurs travaillent actuellement sur l'arriéré d'automatisation qui a déclenché et n'a pas fonctionné pendant l'incident.

2. 21 septembre 2026 à 15:00 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

3. 21 septembre 2026 à 15:39 UTCmonitoring

   Nous travaillons actuellement sur l'arriéré d'automatisation qui n'a pas fonctionné.

4. 21 septembre 2026 à 16:10 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 septembre 2026 à 14:36 UTCinvestigating

   Nous avons reçu une alerte pour des performances inhabituelles lentes dans plusieurs régions. Nous enquêtons.

2. 17 septembre 2026 à 15:12 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 17 septembre 2026 à 15:13 UTCresolved

   Cet incident a été résolu.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 2 septembre 2026 à 18:08 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 2 septembre 2026 à 18:13 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 2 septembre 2026 à 18:14 UTCinvestigating

   Le revers semble avoir complètement résolu les erreurs. Nous suivons de près, mais les utilisateurs devraient pouvoir accéder à nouveau à Asana.

4. 2 septembre 2026 à 18:14 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

5. 2 septembre 2026 à 18:49 UTCresolved

   Cet incident a été résolu.

6. 4 septembre 2026 à 19:52 UTCpostmortem

   Incident : Un système interne responsable de l'échelle automatique de la capacité du serveur de backend dans un de nos clusters de calcul a cessé de remplacer la capacité qui avait été cycleé pendant la maintenance courante. Cela a entraîné une réduction progressive de la capacité disponible sur plusieurs heures. Un déploiement ultérieur a été déclenché avec une capacité insuffisante, ce qui a entraîné l'échec de toutes les nouvelles demandes pour ce groupe de calcul. Pour atténuer l'impact, nous sommes revenus à une précédente révision de la version, qui avait encore une capacité suffisante. Impact: Pendant environ 30 minutes, les clients dont le trafic a été géré par ce cluster de calcul ont vu des temps d'arrêt complets; d'autres clients n'ont pas été touchés. Aucune donnée client n'a été perdue. Aller de l'avant: Nous avons ajouté une surveillance supplémentaire pour détecter ce type de défaillance d'échelle de capacité beaucoup plus tôt, et nous avons ajouté des mesures de protection pour empêcher les déploiements de déplacer le trafic avant que la capacité saine suffisante soit confirmée. Notre métrique considère une moyenne pondérée de temps d'arrêt vécu par les utilisateurs dans chaque centre de données. Le nombre de minutes d'arrêt indiqué reflète cette moyenne pondérée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 août 2026 à 15:14 UTCinvestigating

   Nous enquêtons sur les alertes pour les erreurs de performance lente et d'application.

2. 31 août 2026 à 15:55 UTCinvestigating

   Nous continuons d'étudier la question; nous avons repris les changements récents et nous nous efforçons d'identifier la source des erreurs.

3. 31 août 2026 à 16:24 UTCinvestigating

   Nous avons fait des modifications de configuration et voyons une récupération partielle, mais nous continuons à voir des erreurs élevées.

4. 31 août 2026 à 16:47 UTCmonitoring

   Nous avons appliqué un correctif pour voir des signes de rétablissement.

5. 31 août 2026 à 17:18 UTCresolved

   Les symptômes se sont rétablis. Nous continuerons de surveiller et de prioriser une rétrospective pour comprendre et prévenir des incidents semblables à l'avenir.

6. 2 septembre 2026 à 21:29 UTCpostmortem

   Nous avons travaillé à ajouter une couche de mise en cache à notre pipeline de mise à jour, en l'accordant soigneusement et en le roulant progressivement. Le mercredi 26 août, nous l'avons activé pour la plupart des cas d'utilisation, et il a d'abord bien fonctionné. Le lundi 31 août, une combinaison de changements d'infrastructure non liés et de trafic de pointe a poussé le cache au-delà de ses limites d'échelle. Une fois que ce seuil a été franchi, le cache est devenu inutilisable, et de nombreux pods servant le trafic de lecture pour l'application Asana ne pouvaient plus le servir. Nous avons atténué l'incident en renvoyant le système à l'aide du chemin de code précédent, non plafonné. Le retour a été réussi, mais la reprise a pris plus de temps que nous ne nous attendions pour cette catégorie de questions. Une analyse plus complète est en cours. Nous ferons le suivi des causes profondes, des éléments d'action et des améliorations, y compris la raison pour laquelle la reprise a pris autant de temps qu'elle l'a fait. Nous avons été complètement en baisse pour environ 25% de nos utilisateurs, pendant 2 heures, 15 minutes.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 6 août 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 juillet 2026 à 18:49 UTCidentified

   Nous voyons des erreurs pour une partie (environ 10%) des utilisateurs aux États-Unis pour l'application web Asana. Nous avons identifié la cause fondamentale et nous travaillons à identifier une résolution.

2. 7 juillet 2026 à 19:12 UTCmonitoring

   Nous avons mis en oeuvre une mesure d'atténuation et nous surveillons pour assurer le rétablissement.

3. 7 juillet 2026 à 19:21 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

4. 7 juillet 2026 à 19:24 UTCresolved

   Cet incident a été résolu.

5. 8 juillet 2026 à 21:28 UTCpostmortem

   **Incident**: Un changement de configuration a par inadvertance supprimé une ressource essentielle requise par l'un de nos services. Bien que les infrastructures existantes continuent de fonctionner normalement, les nouvelles infrastructures ne peuvent pas être prêtes. Au fur et à mesure que le trafic du matin augmentait, il y avait un écart croissant entre les demandes reçues et la capacité de notre système à les traiter, ce qui a entraîné une dégradation du service. Nous avons résolu le problème en restaurant manuellement la ressource manquante et en corrigeant le changement de configuration qui a causé son retrait. (en milliers de dollars) **Impact**: Pendant environ 1,5 heure, un sous-ensemble de clients a connu une panne complète de notre application Web et des applications de bureau. Pendant cette période, les utilisateurs touchés n'ont pas pu accéder à Asana. Aucune donnée client n'a été perdue. (en milliers de dollars) **Avancer**: Nous appliquons des garanties supplémentaires dans notre processus de gestion de la configuration afin d'éviter que les ressources essentielles ne soient retirées par inadvertance. Nous améliorons également nos systèmes de surveillance pour détecter la dégradation plus tôt, avant qu'elle n'affecte l'accès des clients. (en milliers de dollars) Notre métrique considère une moyenne pondérée de temps d'arrêt vécu par les utilisateurs dans chaque centre de données. Le nombre de minutes d'arrêt indiqué reflète cette moyenne pondérée.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 29 avril 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 avril 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 avril 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 avril 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 mars 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 mars 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 mars 2026 à 18:34 UTCresolved

   This incident has been resolved.

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

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

3. 2 mars 2026 à 09:02 UTCinvestigating

   We are continuing to investigate this issue.

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

   This incident has been resolved.

1. 5 février 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 février 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 janvier 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 janvier 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 janvier 2026 à 03:20 UTCmonitoring

   We are continuing to monitor for any further issues.

4. 26 janvier 2026 à 03:29 UTCresolved

   This incident has been resolved.

1. 22 janvier 2026 à 17:48 UTCinvestigating

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

2. 22 janvier 2026 à 17:51 UTCinvestigating

   We are continuing to investigate this issue.

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

   This incident has been resolved.

7. 27 janvier 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 janvier 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 janvier 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 janvier 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 janvier 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 novembre 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.