Asana Outage History

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**.

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**.

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.

Incident: [Cloudflare experienced an outage](https://blog.cloudflare.com/18-november-2025-outage/) that impacted the Workers KV service, a storage infrastructure service our MCP server relies on. This resulted in increased error rates and failed requests for a portion of our MCP traffic over the span of 3 hours. ‌ Impact: Approximately 100 users making requests to the MCP server received error responses or were unable to reach the server from 2025-11-18 11:20 UTC through 14:20 UTC. ‌ Moving forward: We are investing in our MCP Server to improve its resilience to KV store outages, and are investigating ways to reduce the overall impact of Cloudflare outages. 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.

We had approximately 1 hour of full downtime, where the Asana application was unavailable for most of our users. There was no data loss or security vulnerability. ‌ A routine configuration change affected the Asana application globally. While refactoring the configuration consumption, we missed an unintended side effect, causing the app to fail loading in all regions. We reverted the change and restarted servers for full recovery.

**Incident**: Around 2025-08-17 23:35, a conflict occurred between two database management systems. For most Asana customers, database locks prevented execution of background actions, automations, and webhooks were delayed. **Impact**: Users experienced delays in asynchronous operations, including automations and webhooks. Core application functions remained available and operational throughout the incident. No customer data was lost. The incident lasted approximately 2 hours, after which delayed operations ran normally. **Moving forward**: Asana engineers completed an investigation into the root cause, and have implemented changes to prevent the conflict between these systems. We are also reviewing our upgrade and management processes to be resilient against similar issues in the future. 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.

**Incident**: A configuration change unintentionally blocked internal network access between application components. This change was identified as the cause of downtime and reverted. **Impact**: The Asana App and API were unavailable for 24 minutes. App and API traffic recovered over the next 5 minutes, and Automations & Background Actions recovered over 10 minutes. **Moving forward**: We have completed a redesign of our core application architecture to better protect our services from disruption by segmentation into independent sections, or "cells." We are considering ways we can leverage this architecture to roll out configuration changes like the one which triggered this incident more gradually and carefully across our systems to ensure safety & stability. 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.

**Incident**: A configuration change triggered a bug affecting how internal systems process configuration data, leading to application downtime. The issue impacted internal server uptime, resulting in approximately 28 minutes of degraded service on March 25, 2025, from 22:32 UTC to 23:00 UTC \(3:32 PM to 4:00 PM PDT\). ‌ **Impact**: During the incident, customers experienced difficulties accessing Asana on web and mobile apps, including login failures and errors while using the application. Internal services gradually recovered after the problematic change was reverted. ‌ **Moving forward**: We are enhancing our configuration validation processes to prevent similar issues. Additional monitoring and safeguards are being introduced to ensure rapid identification and recovery from similar incidents. ‌ 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.

Incident: At 2025-02-06 15:37 UTC, a configuration change caused some of our servers to crash, leading to complete downtime for 20 minutes. We rolled back the configuration, but this event triggered a cascade failure in network routing components; our systems recovered over the next 30 minutes, with full recovery by 2025-02-06 16:30. Impact: Users were unable to use Asana during this event in all regions, with downtime including App, API, and Mobile. No customer data was lost. Moving forward: We have added validation to prevent a repeat of this issue, and are updating our networking components to avoid this form of cascade failure. We will be moving to staged configuration rollouts to identify this class of issue without causing downtime for customer traffic. 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.

Incident: Starting at 2025-02-05 21:05 UTC, a configuration change caused a large increase in server logs, overloading logging infrastructure and causing server restarts. This caused cascade failure as other servers were overloaded. The configuration change was reverted, and our application recovered after the servers restarted, with recovery by around 2025-02-05 21:30. Impact: Users saw errors loading our application and loading data within the application. No customer data was lost. Moving forward: We have removed the source of logs which resulted in overload, and are improving monitoring and resilience of the system which triggered failure. We will also be moving to staged configuration rollouts to help reduce or avoid customer impact for similar issues. 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.