59 Asana incidents · 2024年2月 — official updates, affected components, duration and resolution details.
当社は、非同期作業を処理するためのシステムにおいて重要な劣化を持っています。 以前はWebアプリケーションユーザーからクラッシュしていましたが、解決したようです。 非同期作業を監視しています.
問題のあるワークロードを悪用し、回復を見ていると思います.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
アサナサービスは、現在、主要なサービスの中断を経験しています。 原因を特定し、修正を加える上で作業しています。 これは、すべてのサービスとすべての地域に影響を与えます.
私たちは、この停電の原因を特定し、これを対処するための変更を開始しました。 回復の兆候がいくつか見られ、回復を確認したら更新を投稿します.
この問題の修正には引き続き取り組んでいます。
修正を加えました。 エラー率とトラフィックの回復を観察し、このインシデントが解決されると確信しています。 72時間以内に郵便物/RCAを掲示します.
**事件:** ダイナモDB によるセキュリティを標的としたインフラ更新で、アサナの生産環境全体でアクセス不能になります。 この変更は、生産分離のイニシアチブに関連し、メタデータやルーティングトラフィックに使用するDynamoDBテーブルを使用することができないすべての生産サービスを残した方法で適用されました。 変更が変更されたら、サービスが通常の操作に戻りました。 **影響:** アサナサービスは2026-10-21 15:21 UTC-15:51 UTC、および15:05 UTC-15:55 UTCを含む20分以上利用できませんでした。 また、衝撃期間中のバックグラウンドアクションの遅延が発生しました。 事故の終端の回復は16:00 UTCで完了しました。 **進むこと:** このクラスのエラーをキャッチするために展開プロセスを更新しています。 同様の変更の段階的なロールアウトを可能にした分離システムに移行し、試作前のテストで誤構成を検知します。 当社のメトリックは、各データセンターでユーザーによって経験される重みのある稼働時間の平均値を考慮しています。 ダウンタイムの分数は、この重み平均を反映しています.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
現在、システムリカバリーが進んでおり、状況を監視し、回復を徹底しています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です。
事件が解決しました.
公式のインシデント更新を自動翻訳しています。
EU地域では運営していないルールや自動化のレポートを聞きました。 問題のソースを識別し、新しい自動化のためにそれを固定しました。 当社のエンジニアは、現在、インシデント中にトリガーおよび実行されていない自動化のバックログに取り組んでいます.
この問題の修正には引き続き取り組んでいます。
現在、実行しなかった自動化のバックログを通して、当社の取り組みを行っています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
複数の地域で異常な低速性能の警告をいただきました。 調査中です.
今後もこの問題について調査を続けてまいります.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
今後もこの問題について調査を続けてまいります.
ロールバックは完全にエラーを解決しているようです。 密接に監視していますが、再びAsanaにアクセスできるはずです.
修正を実装し、結果を監視しています.
この事件は解決しました.
インシデント:コンピュートクラスターの1つに自動的にバックエンドサーバー容量をスケーリングする責任の社内システムが、定期的なメンテナンス中にサイクルアウトされた容量を交換しなくなりました。 これにより、数時間以上使用可能な容量のグラデーション削減が発生しました。 その後のデプロイメントは、不十分な容量で有効化され、そのコンピュートクラスターが失敗するすべての新しいリクエストを引き起こしました。 インパクトを緩和するためには、以前のリリースリビジョンに戻り、まだ十分な容量を持ちました。 影響:約30分、このコンピュートクラスターが十分にダウンタイムを見たことでトラフィックを処理した顧客は、他の顧客は影響を受けませんでした。 顧客データが失われない 転送先: このタイプの容量のスケーリング障害をはるかに前に検出するために追加の監視を追加し、十分な健康容量が確認される前に、展開がトラフィックをシフトするのを防ぐための保護策を追加しました。 当社のメトリックは、各データセンターのユーザーによって経験される重みのある稼働時間の平均を考慮します。 ダウンタイムの分数がこの重み平均を反映しています。
公式のインシデント更新を自動翻訳しています。
パフォーマンスやアプリケーションのエラーを遅らせるためのアラートを調査しています.
私たちは、問題を調査し続けています。私たちは、最近の変更を反転し、エラーのソースを特定するために働いています.
構成変更を行い、部分的な回復を見てきましたが、今後も高まる誤差を引き続き見ていきます.
修正は回復の兆候を見ています.
ユーザーフェース症状が回復しました。 今後も監視し続けていきますが、今後同様の事故を未然に把握し、防止するためのレトロスペクティブを優先します.
アップデートパイプラインにキャッシュレイヤーを追加し、慎重に調整し、徐々にロールアウトします。 8月26日(水)は、ほとんどのユースケースに対応し、当初はうまくいきます。 8月31日(月)、無関係のインフラ変更とピークトラフィックの組み合わせで、スケール制限を過ぎたキャッシュを押しました。 しきい値が交差したら、キャッシュは使えなくなり、Asanaアプリケーション用の読み取りトラフィックを提供する多くのPodはもはや機能しません。 以前の非キャッシュされたコードパスを使用するシステムを再変換することにより、インシデントを緩和しました。 逆転は成功しましたが、この問題のクラスが期待するよりも回復は長かったです。 完全な分析が進行中です。 根本的な原因、行動項目、改善を追っていきます。その理由は、回復がいつまでも時間がかかりました。 ユーザーの約25%、約2時間15分.
公式のインシデント更新を自動翻訳しています。
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.
アメリカのアサナウェブアプリのユーザー数(約10%)のエラーが出ています。 根本原因を特定し、分解能の特定に取り組んでいます.
緩和を実施し、回復を確実にするために監視しています.
今後の問題がないか引き続き監視しています。
この事件は解決しました.
**事件**: 構成変更は、当社のサービスの1つに必要な重要なリソースを意図的に削除しました。 既存のインフラは正常に動作し続けながらも、新規模のインフラは準備が整えられません。 朝の交通が増加するにつれて、着信リクエストとシステムの容量のギャップが増加し、サービス劣化を引き起こしました。 不足しているリソースを手動で復元し、その削除を引き起こした構成変更を修正することによって、問題を解決しました。 **影響**: 約1.5時間、お客様のサブセットは、当社のWebアプリケーションとデスクトップアプリケーションをフル活用しました。 現時点では、影響を受けたユーザーはアサナにアクセスできませんでした。 顧客データが失われない **先に進む**: 重要なリソースが不変に削除されるのを防ぐため、構成管理プロセスで追加の保護策を実装しています。 また、モニタリングシステムを強化し、お客様のアクセスに影響を与える前に劣化を早期に検知します。 当社のメトリックは、各データセンターでユーザーによって経験される重みのある稼働時間の平均値を考慮しています。 ダウンタイムの分数は、この重み平均を反映しています.
公式のインシデント更新を自動翻訳しています。
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.
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**.
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.
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**.
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.
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.
This incident has been resolved.
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.
We no longer see impact on our servers. We're monitoring, as the AWS incident has not resolved.
We are continuing to investigate this issue.
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
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
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
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.
This incident has been resolved.
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.
Our engineers have rolled back recent changes to our primary monitoring systems, and our API and mobile systems are fully operational.
We are investigating an elevated rate of API errors as well as delays reflecting changes for the App in EU.
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.
We are continuing to monitor for any further issues.
This incident has been resolved.
We're investigating an outage, it looks like no one is able to reach the Asana webapp.
We are continuing to investigate this issue.
We've identified the cause and have rolled back. Based on our monitoring, we should be recovered for some users.
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.
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.
This incident has been resolved.
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.
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.
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.
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.
Thank you for your patience. Service is fully restored, and the Asana web app is back to normal functionality.
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.
