Asana driftsforstyrrelser

1. 23. oktober 2026 kl. 23.57 UTCinvestigating

   Vi har en betydelig forringelse i vores system til behandling asynkron arbejde. Vi tidligere havde nogle nedbrud fra web applikation brugere, men det synes at have løst. Vi overvåger asynkron arbejdet.

2. 24. oktober 2026 kl. 00.03 UTCmonitoring

   Vi har sat nogle opgaver på pause, og vi tror, vi er ved at komme os.

3. 24. oktober 2026 kl. 02.35 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. oktober 2026 kl. 15.33 UTCidentified

   Asana-tjenesterne oplever i øjeblikket en stor forstyrrelse af tjenesten. Vi har identificeret en sandsynlig årsag og arbejder på at anvende et fix. Dette berører alle tjenester og alle regioner.

2. 21. oktober 2026 kl. 15.51 UTCidentified

   Vi har identificeret årsagen til denne afbrydelse og har iværksat ændringer for at løse dette problem. Vi ser nogle tegn på bedring, og vil sende en opdatering, når vi har bekræftet bedring.

3. 21. oktober 2026 kl. 16.08 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

4. 21. oktober 2026 kl. 16.10 UTCresolved

   Fixet er blevet anvendt. Vi har observeret bedring af fejlrater og trafik, og vi mener, at denne hændelse nu er løst. Vi sender en post-mortem / RCA inden 72 timer.

5. 24. oktober 2026 kl. 00.22 UTCpostmortem

   * * Tilfælde: * * En infrastrukturopdatering rettet mod sikkerhed fik DynamoDB til at blive utilgængelige på tværs af Asanas produktionsmiljø. Denne ændring var relateret til en produktion isolation initiativ, og blev anvendt på en måde, der gjorde alle vores produktionstjenester ude af stand til at bruge DynamoDB tabeller, som vi bruger til metadata og routing trafik. Når ændringen blev vendt tilbage vores tjenester vendte tilbage til normale operationer. * * Indvirkning: * * Asana-tjenester var helt utilgængelige i ca. 30 minutter, 2026- 10- 21 15: 21 UTC- 15: 51 UTC, og for det meste ikke tilgængelige i yderligere 20 minutter, herunder 15: 05 UTC- 15: 55 UTC. Dette forårsagede også forsinkelse for baggrundshandlinger i påvirkningsperioden; inddrivelse efter afslutningen af hændelsen afsluttet kl 16: 00 UTC. * * Fremad: * * Vi opdaterer implementeringsprocessen for at fange denne fejlklasse. Vi vil bevæge os til et isolationssystem, der giver mulighed for mere gradvis udrulning af lignende ændringer, så vi kan opdage fejlkonfiguration i præ-produktion test. Vores metrisk anser et vægtet gennemsnit af oppetid oplevet af brugerne på hvert datacenter. Antallet af minutter med nedetid, der er vist, afspejler dette vægtede gennemsnit.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 30. september 2026 kl. 14.31 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 30. september 2026 kl. 15.09 UTCidentified

   Vi ser i øjeblikket en genopretning af systemet og overvåger aktivt situationen for at sikre fuld genopretning.

3. 30. september 2026 kl. 15.21 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. september 2026 kl. 12.14 UTCinvestigating

   Vi undersøger i øjeblikket problemet.

2. 29. september 2026 kl. 15.25 UTCresolved

   Hændelsen er løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. september 2026 kl. 14.59 UTCidentified

   Vi har hørt rapporter om regler og automatiseringer, der ikke kører i EU-regionen. Vi har identificeret kilden til problemet og fikseret det for nye automatiseringer udløser går fremad. Vores ingeniører arbejder i øjeblikket på den efterslæb af automatiseringer, der udløste og ikke køre under hændelsen.

2. 21. september 2026 kl. 15.00 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

3. 21. september 2026 kl. 15.39 UTCmonitoring

   Vi arbejder os igennem de manglende automatiseringer.

4. 21. september 2026 kl. 16.10 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 17. september 2026 kl. 14.36 UTCinvestigating

   Vi modtog en advarsel om usædvanlig langsom præstation i flere regioner. Vi efterforsker.

2. 17. september 2026 kl. 15.12 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 17. september 2026 kl. 15.13 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 2. september 2026 kl. 18.08 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 2. september 2026 kl. 18.13 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 2. september 2026 kl. 18.14 UTCinvestigating

   Den rollback synes at have helt løst fejl. Vi overvåger nøje, men brugerne bør kunne få Asana igen.

4. 2. september 2026 kl. 18.14 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

5. 2. september 2026 kl. 18.49 UTCresolved

   Denne hændelse er blevet løst.

6. 4. september 2026 kl. 19.52 UTCpostmortem

   Hændelse: Et internt system med ansvar for automatisk skalering af backend-serverkapacitet i en af vores computerklynger stoppede udskiftningen af kapacitet, der var blevet cyklet ud under rutinemæssig vedligeholdelse. Dette medførte en gradvis reduktion af den disponible kapacitet over flere timer. En efterfølgende deployering blev aktiveret med utilstrækkelig kapacitet, hvilket fik alle nye anmodninger for at beregne klynge til at mislykkes. For at afbøde virkningerne vendte vi tilbage til en tidligere udgivelsesrevision, som stadig havde tilstrækkelig kapacitet. Indvirkning: I ca. 30 minutter, kunder, hvis trafik blev håndteret af denne computer klynge oplevede fuld nedetid; andre kunder var upåvirket. Ingen kundedata blev tabt. Fremover: Vi har tilføjet yderligere overvågning for at opdage denne type kapacitet- skalering fiasko meget tidligere, og har tilføjet sikkerhedsforanstaltninger for at forhindre deployeringer i at flytte trafik, før tilstrækkelig sund kapacitet bekræftes. _ Vores metrisk anser et vægtet gennemsnit af oppetid oplevet af brugere på hvert datacenter. Antallet af minutter af nedetid vist afspejler dette vægtede gennemsnit. _

Automatisk oversat fra den officielle hændelsesopdatering.

1. 31. august 2026 kl. 15.14 UTCinvestigating

   Vi undersøger indberetninger for langsom ydeevne og applikationsfejl.

2. 31. august 2026 kl. 15.55 UTCinvestigating

   Vi fortsætter med at undersøge spørgsmålet. Vi har vendt tilbage til de seneste ændringer og arbejder på at identificere kilden til fejlene.

3. 31. august 2026 kl. 16.24 UTCinvestigating

   Vi har lavet konfigurationsændringer og se delvis opsving, men vi fortsætter med at se nogle forhøjede fejl.

4. 31. august 2026 kl. 16.47 UTCmonitoring

   Vi har fundet tegn på bedring.

5. 31. august 2026 kl. 17.18 UTCresolved

   Symptomerne er kommet sig. Vi vil fortsætte med at overvåge, og vil prioritere en retrospektiv at forstå og forhindre lignende hændelser i fremtiden.

6. 2. september 2026 kl. 21.29 UTCpostmortem

   Vi har arbejdet på at tilføje en caching lag til vores opdatering rørledning, tuning det omhyggeligt og rulle det ud gradvist. Onsdag den 26. august aktiverede vi den for de fleste brugssager, og den fungerede i første omgang godt. Mandag den 31. august skubbede en kombination af ikke-relaterede infrastrukturændringer og myldretid cachen forbi sine skaleringsgrænser. Når denne tærskel blev overskredet, cachen blev ubrugelig, og mange bælge servering læse trafik for Asana ansøgning kunne ikke længere tjene det. Vi afbødede hændelsen ved at vende systemet tilbage for at bruge den tidligere, ikke-cache kode sti. Returneringen var vellykket, men opsvinget tog længere tid, end vi kunne forvente for denne klasse af spørgsmål. En mere omfattende analyse er i gang. Vi vil følge op med grundlæggende årsager, handling elementer, og forbedringer, herunder hvorfor inddrivelse tog så længe det gjorde. Vi var helt nede i omkring 25% af vores brugere, i 2 timer, 15 minutter.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. august 2026 kl. 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. juli 2026 kl. 18.49 UTCidentified

   Vi ser fejl for en del (omkring 10%) af brugere i USA til Asana webapp. Vi har identificeret årsagen og arbejder på at finde en løsning.

2. 7. juli 2026 kl. 19.12 UTCmonitoring

   Vi har gennemført en afbødning og overvåger for at sikre genopretning.

3. 7. juli 2026 kl. 19.21 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

4. 7. juli 2026 kl. 19.24 UTCresolved

   Denne hændelse er blevet løst.

5. 8. juli 2026 kl. 21.28 UTCpostmortem

   * * Tilfælde * *: En konfiguration ændring utilsigtet fjernet en kritisk ressource, der kræves af en af vores tjenester. Selv om den eksisterende infrastruktur fortsat fungerer normalt, kunne den nyskalerede infrastruktur ikke blive klar. Efterhånden som morgentrafikken steg, var der en voksende kløft mellem indgående anmodninger og vores systems evne til at håndtere dem, hvilket resulterede i forringelse af tjenesten. Vi løst problemet ved manuelt at genoprette den manglende ressource og korrigere den konfiguration ændring, der forårsagede dens fjernelse. Name * * Indvirkning * *: I ca. 1,5 timer oplevede en delmængde af kunder et fuldt udfald af vores webapplikationer og desktop-applikationer. I denne periode var de berørte brugere ude af stand til at få adgang til Asana. Ingen kundedata blev tabt. Name * * Fremad * *: Vi gennemfører yderligere sikkerhedsforanstaltninger i vores konfigurationsproces for at forhindre, at kritiske ressourcer utilsigtet fjernes. Vi forbedrer også vores overvågningssystemer til at opdage nedbrydning tidligere, før det påvirker kundernes adgang. Name Vores metrisk anser et vægtet gennemsnit af oppetid oplevet af brugerne på hvert datacenter. Antallet af minutter med nedetid, der er vist, afspejler dette vægtede gennemsnit.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. april 2026 kl. 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. april 2026 kl. 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. april 2026 kl. 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. april 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 18.34 UTCresolved

   This incident has been resolved.

1. 1. marts 2026 kl. 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. marts 2026 kl. 21.03 UTCinvestigating

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

3. 2. marts 2026 kl. 09.02 UTCinvestigating

   We are continuing to investigate this issue.

4. 2. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 05.58 UTCresolved

   This incident has been resolved.

1. 5. februar 2026 kl. 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. februar 2026 kl. 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. januar 2026 kl. 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. januar 2026 kl. 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. januar 2026 kl. 03.20 UTCmonitoring

   We are continuing to monitor for any further issues.

4. 26. januar 2026 kl. 03.29 UTCresolved

   This incident has been resolved.

1. 22. januar 2026 kl. 17.48 UTCinvestigating

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

2. 22. januar 2026 kl. 17.51 UTCinvestigating

   We are continuing to investigate this issue.

3. 22. januar 2026 kl. 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. januar 2026 kl. 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. januar 2026 kl. 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. januar 2026 kl. 19.00 UTCresolved

   This incident has been resolved.

7. 27. januar 2026 kl. 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. januar 2026 kl. 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. januar 2026 kl. 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. januar 2026 kl. 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. januar 2026 kl. 21.50 UTCresolved

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

1. 24. november 2025 kl. 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.