背景工作部分中断
Outage重大事件
受影响的组件
Automations and Background ActionsWebhooks and Event StreamsNotifications
- investigating
我们处理同步工作的系统严重退化。 我们之前从网络应用程序用户那里发生了一些故障,但似乎已经解决了。 我们正在监视同步工作.
- monitoring
我们暂停了一些有问题的工作量,我们认为我们看到了复苏.
- resolved
这一事件已经得到解决.
自动翻译自官方事件更新。
59 Asana incidents · 2024年2月 — official updates, affected components, duration and resolution details.
我们处理同步工作的系统严重退化。 我们之前从网络应用程序用户那里发生了一些故障,但似乎已经解决了。 我们正在监视同步工作.
我们暂停了一些有问题的工作量,我们认为我们看到了复苏.
这一事件已经得到解决.
自动翻译自官方事件更新。
阿萨纳服务目前受到重大干扰。 我们已查明一个可能的原因,并正在努力实施一个解决办法。 这影响到所有服务和所有区域.
我们查明了这种停产的原因,并开始作出改变来解决这一问题。 我们正在看到一些恢复的迹象, 并将发布更新 一旦我们确认恢复.
我们正在继续努力解决这个问题。
修行已施. 我们看到了误差率和流量的恢复,相信这一事件现在已经得到解决。 我们将在72小时之内进行验尸.
** 事件:** 以安全为目标的基础设施更新使得DynamoDB在Asana的生产环境中变得无法进入. 这一变化与生产隔离倡议有关,其应用方式使我们所有的生产服务无法使用DynamoDB表格,我们使用这些表格进行元数据和线路流量。 一旦改变,我们的服务恢复正常。 ** 影响:** 阿萨纳服务大约在30分钟内完全无法使用,2026-10-21 15:21 UTC-15:51 UTC,大部分在再20分钟内无法使用,包括15:05 UTC-15:55 UTC. 这也导致在撞击期间背景行动出现延误;事件结束后恢复工作于协调世界时16:00完成. ** 前进:** 我们正在更新部署程序,以赶上这种错误。 我们将转向一个隔离系统,能够更逐步地推出类似的变化,使我们能够发现生产前测试中的配置错误。 我们的衡量尺度考虑每个数据中心用户的正常时间加权平均数。 显示的停机时间分钟数反映了这一加权平均数.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
我们目前正在看到系统恢复,并正在积极监测局势,以确保全面恢复.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们目前正在调查这个问题。
此事已决.
自动翻译自官方事件更新。
我们听说欧盟地区没有运行规则和自动化系统 我们已经确定了问题的来源,并把它固定在新的自动化触发器上。 我们的工程师目前正在研究在事故中引发和未运行的积压自动化设备.
我们正在继续努力解决这个问题。
目前我们正在努力解决未运行的积压自动化问题.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们收到了关于几个区域异常缓慢表现的警报。 我们在调查.
我们正在继续调查这一问题.
这一事件已经得到解决.
自动翻译自官方事件更新。
我们目前正在调查这一问题.
我们正在继续调查这一问题.
倒转似乎已经完全解决了错误. 我们正在密切监控,但用户应该能够再次访问Asana.
一项措施已经执行,我们正在监测结果.
这一事件已经得到解决.
事件:一个负责在我们的一个计算集群中自动缩放后端服务器容量的内部系统停止了更换在例行维护中被循环淘汰的能力. 这导致现有能力在几个小时内逐渐减少。 随后的部署因能力不足而启动,导致计算组的所有新请求都失败。 为了减轻这种影响,我们恢复了先前的版本修订,该版本仍然有足够的能力。 影响:在大约30分钟的时间里,由这个计算组处理流量的客户看到完全停机;其他客户没有受到影响。 没有丢失客户数据。 前进:我们增加了额外的监测,以便更早地发现这种能力扩能故障,并增加了保障措施,以防止部署人员在证实有足够的健康能力之前转移交通。 我们的度量衡考虑的是每个数据中心用户经历的升起时间加权平均值. 显示故障时间的分数反映了这一加权平均值。
自动翻译自官方事件更新。
我们正在调查慢性能和应用程序错误的警报.
我们正在继续调查这一问题;我们已恢复了最近的变化,并正在努力查明出错的根源.
我们进行了配置修改并看到部分恢复,但我们继续看到一些更高的错误.
我们应用了一个固定 正在看到恢复的迹象.
用户化症状已恢复. 我们将继续监控,并将优先进行回溯,以了解和防止今后发生的类似事件.
我们一直在努力在更新的管道中增加一个缓冲层,仔细调整并逐步推出。 8月26日,星期三,我们允许它用于大多数案件,它起初表现良好。 8月31日星期一,不相关的基础设施变化和高峰流量组合将缓存推超了缩放限度. 一旦突破了这个阈值,缓存就变得无法使用,许多为Asana应用程序服务读取流量的出舱已经无法服务了. 我们通过恢复系统来使用先前的,无标记的代码路径来缓解事件. 恢复是成功的,但恢复的时间比我们预计的这一类问题要长。 目前正在进行更全面的分析。 我们将就根源、行动项目和改善采取后续行动,包括为什么恢复需要像恢复那样长的时间。 大约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%)在Asana Webapp上出现错误。 我们已经查明了根源,并正在努力找出解决办法.
我们实施了缓解措施并正在进行监测,以确保恢复.
我们正在继续监测任何其他问题.
这一事件已经得到解决.
** 事件**: 配置的改变无意中取消了我们一个服务部门需要的关键资源。 虽然现有基础设施继续正常运行,但新规模的基础设施无法准备就绪。 随着晨间交通量的增加,收到的请求与我们系统处理请求的能力之间的差距越来越大,导致服务退化. 我们通过人工恢复所缺资源并纠正导致其删除的配置变化来解决这个问题。 ** 影响**: 大约1.5小时以来,一个子集的客户经历了我们的网络应用程序和桌面应用程序的全面停用. 在此期间,受影响的用户无法访问Asana。 没有丢失客户数据。 ** 前进**: 我们正在我们的配置管理进程中实施更多的保障措施,以防止重要资源被无意取走。 我们还正在加强我们的监测系统,以更早地发现退化,以免影响客户的准入。 我们的衡量尺度考虑每个数据中心用户的正常时间加权平均数。 显示的停机时间分钟数反映了这一加权平均数.
自动翻译自官方事件更新。
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.