Pricing
Status historyRSS updatesStatus API

Powered by Uptimus

    Loom driftsforstyrrelser

    10 Loom incidents · april 2025 — official updates, affected components, duration and resolution details.

    Tilbage til aktuel status

    Flere Atlantiske tjenester oplever problemer

    Startede 8. maj 2026 kl. 03.00 UTC · 16h 45m

    IssuesMindre hændelse
    Berørte komponenter
    ViewingAuthenticationLoom AIRecording
    1. 8. maj 2026 kl. 03.00 UTCinvestigating

      Vi oplever problemer med flere atlantiske produkter. Vores hold undersøger yderligere og flere opdateringer, herunder vil blive delt inden for 1 time.

    2. 8. maj 2026 kl. 04.10 UTCidentified

      Vi har identificeret, at den grundlæggende årsag til problemet er relateret til en infrastruktur afbrydelse fra vores offentlige cloud-udbyder. Vi arbejder tæt sammen med dem for at mindske dette problem. Vi vil give yderligere opdateringer, når de bliver tilgængelige.

    3. 8. maj 2026 kl. 04.10 UTCidentified

      Vores team fortsætter med at arbejde på at afbøde den infrastruktur udfald fra vores offentlige cloud-udbyder. Vi vil give yderligere opdateringer, når de er tilgængelige.

    4. 8. maj 2026 kl. 04.10 UTCidentified

      Vi arbejder fortsat med vores offentlige cloud-udbyder for at mindske dette problem. Vi begynder at se en vis bedring i regioner uden for det østlige USA, men brugerne globalt kan stadig opleve problemer med visse produktfunktioner. Disse er anført i bunden af hver produktside.

    5. 8. maj 2026 kl. 05.53 UTCmonitoring

      Det underliggende problem i den offentlige infrastruktur, som påvirkede en synkront sagsbehandling, er blevet afbødet, og alle de berørte tjenester er ved at komme sig. Vi arbejder nu på at rydde tilbage i kø begivenheder, hvilket betyder, at nogle handlinger (såsom meddelelser, automatisering udløser, og data synkronics) kan være i forringet tilstand. Vi vil fortsætte med at overvåge og levere opdateringer, når backlog er ryddet.

    6. 8. maj 2026 kl. 08.03 UTCmonitoring

      Vi følger fortsat situationen, efterhånden som tjenesterne kommer sig. Vi er i øjeblikket i færd med at rydde op i baggrunden af begivenheder i køen. Vi vil give en yderligere opdatering om cirka en time.

    7. 8. maj 2026 kl. 11.12 UTCmonitoring

      Vores tjenester er nu fuldt operationelle. Vi fortsætter med at spille alle begivenheder, der blev savnet under hændelsen, og gør gode fremskridt. Vi vil give en yderligere opdatering, når replays er færdige. Hvis du oplever nogen løbende problemer, bedes du kontakte vores support team. Vi undskylder forstyrrelsen og takker for Deres tålmodighed.

    8. 8. maj 2026 kl. 19.45 UTCresolved

      Den 8. maj 2026, nogle kunder, der udnytter Atlantiske produkter oplevede forhøjede fejlrater og forringet ydeevne. Spørgsmålet er nu løst, og tjenesten fungerer normalt for alle berørte kunder.

    9. 20. maj 2026 kl. 06.57 UTCpostmortem

      Alle datoer og tidspunkter nedenfor er i UTC, medmindre andet er angivet. # # # Oversigt Den 8. maj 2026 mellem 00: 22 og 06: 08, en af vores hosting udbydere lidt en betydelig hændelse i en specifik tilgængelighed zone i prod-øst, som førte til Atlantis kunder oplever forringet ydeevne og forsinkelser i baggrund operationer og automatisering udførelse. Hændelsen startede den 8. maj 2026 kl 00: 22 og blev opdaget inden for 4 minutter af automatiske overvågningssystemer. Vores hold arbejdede på at genoprette kerneluften kl. 06: 08. Den endelige oprensning af backlingede processer og mindre problemer skred frem i etaper derfra blev afsluttet iterativt 19: 15. # # # * * IMPACT * * Den primære infrastruktur, der var berørt af denne hændelse, var den event processing pipeline i prod-øst regionen, som distribuerer begivenheder mellem Atlantis tjenester og understøtter baggrundsoperationer såsom automatisering udførelse, søgning indeksering, meddelelser, tilladelse synkronisering. * Mellem 00: 22 og 06: 08, en infrastruktur hændelse i vores hosting udbyder udløste en indtagelse fiasko i vores begivenhed behandling rørledning. * Ved 02: 50, begivenhed indtagelse blev undladt over til en upåvirket tilgængelighed zone, gradvist genoprette live begivenhed strømme. * Ved 06: 08, pålidelighed for ny indtagelse i prod-øst genvundet til 100%. Det resterende arbejde var at tømme den akkumulerede cross-region efterslæb af meddelelser, som afsluttet kl 17: 00. * Ved 18: 48, Automation havde behandlet deres backlog af begivenheder, der blev oprettet under behandlingen * * Automation * * Mellem kl. 00: 22 og 02: 50 oplevede kunder med automatiseringsregler, der blev udløst af begivenheder, der stammede fra den pro-østlige region, en betydelig reduktion af regelhenrettelser. Under dette vindue blev der ikke affyret automatiseringsregler, fordi de begivenheder, der udløste dem, ikke blev leveret. Regel authoring, besparelse og regler udløst manuelt, af skemaer, eller af webkroge blev ikke påvirket. Klokken 02: 50, den begivenhed behandling infrastruktur mislykkedes over til en upåvirket tilgængelighed zone, genoprette levering af live begivenheder til Automation og tillade nye begivenhedsudløste regler til at begynde at udføre normalt. Begivenheder, der genereres under nedslagsvinduet, skal dog stadig afspilles igen, før forsinkede automatiseringer kunne behandles. Begyndelsen 08: 28, opstrøms tjenester genspillede deres queued begivenheder i en koordineret rækkefølge, og alle genspillede begivenheder blev behandlet af 18: 48. Under replay vinduet, kunder kan have oplevet automatisering regler, der udføres senere end forventet, et lille antal regler, der når daglige behandlingsgrænser på grund af komprimeret replay, og tidsfølsomme regler ikke udfylde som forventet, hvis interne timeout tærskler blev overskredet. * * Jira og Jira Service Management * * Mellem 00: 22 og 02: 50, kunder med lejere hostet i pro-øst regionen oplevede forstyrrelser til Jira og Jira Service Management events-drevne funktioner som automatisering, sammen med en kort periode med forhøjede fejl under infrastruktur failover. Core Jira erfaringer, herunder problemvisning, bestyrelser og projekt navigation, forblev tilgængelige under hele hændelsen. Jira hændelseslevering blev påvirket af den primære virkning, hvilket forhindrede downstream-tjenester i at modtage spørgsmål livscyklusbegivenheder. Dette påvirkede automatiseringsregler udløst af Jira begivenheder, AI agent orkestrering i Jira, meddelelser om spørgsmål opdateringer og overgange, søgning indeksering for nyoprettede eller modificerede spørgsmål, og eventueldrevne integreringer mellem Jira og andre atlantiske produkter. Kl. 02: 50, den begivenhed behandling infrastruktur mislykkedes over til en upåvirket tilgængelighed zone, genoprette levering af nye begivenheder. Alle begivenheder, der blev genereret under slagvinduet, blev fastholdt i en recovery kø og krævede genspil. Dette begyndte kl 08: 28 og afsluttet kl 12: 00. Under replay-vinduet, kan kunderne have oplevet automatisering regler, der udføres senere end forventet, forsinkede meddelelser ankommer timer efter den udløsende handling, midlertidige huller i søgeresultater for indhold skabt eller ændret under påvirkningsvinduet, og AI agent arbejdsgange ikke udfylde som forventet, hvor interne timeout tærskler blev overskredet. * * Sammenhæng * * Mellem kl. 00: 22 og 02: 50 oplevede kunder med lejere, der var hostede i den pro-østlige region, forstyrrelser til eventdrevne tjenester i Confluence. Dette resulterede i forsinkelser i søgning indeksering, meddelelser, automatisering regel udførelse, og tilladelse synkronisering. Den underliggende event processing infrastruktur mislykkedes over til en upåvirket tilgængelighed zone, hvorefter live Confluence operationer genoptaget normalt. Men begivenheder, der blev genereret under påvirkningsvinduet var i kø for at spille igen, og nogle baggrundstjenester forblev forsinket, indtil dette spil og relaterede valideringsarbejde afsluttet. Mellem 10: 14 og 17: 00 blev en bulk replay af alle de queued lejer replay opgaver afsluttet for at gendanne data konsistens. Under og umiddelbart efter genafspilningsvinduet, kan kunderne have oplevet søgeresultater, der ikke afspejler indhold skabt eller ændret under udfald, forsinkede eller manglende meddelelser til side og kommentaraktivitet, automatiseringsregler fyring senere end forventet, og korte forsinkelser i tilladelse synkronisering for lejere, der er afhængige af trinvis identitet synkronisering. * * Bitskovl og rørledninger * * Mellem 00: 22 og 06: 08, kunder, der bruger Bitspande og Pipelines oplevede svigt og forringet funktionalitet på tværs af begivenhedsdrevne arbejdsgange. Core Git operationer, herunder skubbe, trække, og klon, blev ikke påvirket og fortsatte med at fungere normalt under hændelsen. Automatic pipeline triggers initiated by push or pull request events was available under kollisionsvinduet. Sammenfletning køer, brugerdefinerede fletning kontrol, Forge- baserede udløsere, arbejdsrumstilladelser ændringer, og nogle arbejdsrums provisionsstrømme blev også påvirket. Kunder, der bruger fletning køer var ude af stand til at flette pull anmodninger, og nogle pipeline trin mislykkedes, fordi queued arbejde bidrog til forhøjede concurrency grænser. Ved ca. 03: 57, blev Pipelines omkonfigureret til at forbruge begivenheder gennem en alternativ sti, genetablere automatisk rørledning udløser. Sammenfletning køer, brugerdefinerede fletning kontroller, Forge udløser, og andre berørte arbejdsgange blev gradvist restaureret som den underliggende begivenhed behandling infrastruktur genvundet. Alle Bitspace- og Pipelines-tjenester blev bekræftet fuldt operationelle kl. 06.08. Efter inddrivelse, i kø begivenheder blev gennemgået og genspillet, hvor sikkert at gendanne data konsistens til fakturering, revision logning, og andre baggrundsprocesser. * * Identitetstjenester * * Mellem kl. 00: 22 og 02: 50 oplevede kunder med lejere, der var vært i den pro-østlige region, forsinkelser i udbredelsen af identitet og gruppemedlemskab ændringer i de efterfølgende Atlantiske produkter. Kerneidentitetsoperationer, herunder autentificering, login og direkte gruppeledelse, blev ikke påvirket og fortsatte med at fungere normalt under hele hændelsen. Virkningen var begrænset til asynkron, eventueldrevne operationer, der afhænger af hændelsesbehandling rørledningen. Dette omfattede forsinkelser i levering af gruppemedlemskab og brugerprofilændringer til produkter som Jira og Confluence, som påvirkede downstream tilladelse synkronisering og crowd sync strømme. Et lille antal VIDENSKABSbaserede identitetssynkroniseringer og arbejdsgange, hvor der provieres på stedet, oplevede også midlertidige forsinkelser. Efter at event processing infrastruktur genvundet, backed- up identitet og gruppe mappe begivenheder blev genspillet, hvor det var nødvendigt, genoprette downstream sammenhæng for berørte produkter. Ingen identitetsdata blev tabt. Gruppemedlemskab ændringer, brugerprofilopdateringer, og provisionsrelaterede begivenheder, der opstod i løbet af påvirkningsvinduet blev beholdt og behandlet efter inddrivelse. # # # * * MIDLERTIDIGE AKTIONER PLAN & NÆSTE STEPS * * Vi ved, at udfald påvirker din produktivitet. Mens vores overvågnings- og inddrivelsesprocesser hjalp os med at reagere hurtigt, fremhævede denne hændelse muligheder for yderligere at styrke modstandsdygtigheden for eventueldrevne tjenester. Vi prioriterer forbedringer, der vil: * * * Forbedre fejloverdækning * * så kritisk begivenhed behandling kan komme sig mere problemfrit under infrastruktur forstyrrelser. * * * Styrke inddrivelse håndtering * * så genspillede begivenheder kan behandles hurtigere. Vi undskylder til kunder, hvis tjenester blev påvirket under denne hændelse; vi tager øjeblikkelige skridt til at forbedre platformens ydeevne og tilgængelighed. Tak. Atlantisk kundesupport.

    Automatisk oversat fra den officielle hændelsesopdatering.

    Degraded performance of Loom app

    Startede 29. april 2026 kl. 07.00 UTC · 50m

    IssuesMindre hændelse
    Berørte komponenter
    ViewingAuthenticationLoom AIRecording
    1. 29. april 2026 kl. 07.00 UTCinvestigating

      We are investigating degraded performance issues affecting Loom's core functionalities - authentication, recording, viewing and editing looms. We will provide more details within the next hour.

    2. 29. april 2026 kl. 07.50 UTCresolved

      The Team has identified the root cause and the issue has now been resolved, and the impacted services are operating normally. Team will continue to monitor the impacted services.

    Confluence, Jira Mobile and Forge users may experience authentication issues

    Startede 3. februar 2026 kl. 10.19 UTC · 31m

    IssuesMindre hændelse
    Berørte komponenter
    ViewingAuthenticationLoom AIRecording
    1. 3. februar 2026 kl. 10.24 UTCinvestigating

      Customers utilizing Confluence and Jira Mobile may experience disruptions in OAuth authentication flows. Forge installations and invocations might also be disrupted. Our team is actively investigating the same and we shall keep you informed of the progress within next 60 mins or sooner.

    2. 3. februar 2026 kl. 10.50 UTCresolved

      Team has identified the root cause and the issue has now been resolved, and the impacted services are operating normally. Team will continue to monitor the impacted services.

    Some Loom users experiencing no audio when viewing recordings

    Startede 19. november 2025 kl. 22.32 UTC · 7h 7m

    OutageStørre hændelse
    Berørte komponenter
    ViewingAuthenticationLoom AIRecording
    1. 19. november 2025 kl. 22.32 UTCidentified

      We are aware of some customers that are experiencing no audio when viewing their Loom recordings. Our team has identified this issue and is working urgently to restore the audio for these recordings. Please rest assured that the audio has been recorded correctly, and we expect this to be fully available when this incident is resolved. New recordings are no longer impacted by this issue. We will provide an update within two hours with our progress as the team continues to investigate.

    2. 20. november 2025 kl. 00.33 UTCidentified

      Our team believes that we have identified the cause of the issue impacting audio during playback of videos for some customers. As mentioned in our previous updates, new recordings will be working as expected, however videos recorded between 19 Nov 16:51 UTC and 19 Nov 21:30 UTC are expected to be impacted by this issue. A fix for this issue to restore audio to these recordings is now being developed and tested, and we expect to have further update within 2 hours on progress for this resolution.

    3. 20. november 2025 kl. 02.30 UTCidentified

      The fix to resolve issues on audio recordings impacted by this incident is now being prepared for deployment. Currently the expected duration of the rollout is 3 hours, at which point we expect the audio from the impacted recordings to be fully restored. We will provide further update at that time with the progress of the restoration and provide any additional information that may be required.

    4. 20. november 2025 kl. 05.39 UTCresolved

      The rollout of the fix for impacted videos without audio has now completed. Customers should now be able to review existing videos without audio and see that it has been properly restored. If you are continuing to see any issues with playback of your videos, please reach out to Loom support for assistance. We apologize for any inconvenience caused by this issue.

    Loomydelse forringet

    Startede 27. oktober 2025 kl. 15.35 UTC · 6h 25m

    OutageStørre hændelse
    Berørte komponenter
    ViewingAuthenticationLoom AIRecording
    1. 27. oktober 2025 kl. 15.35 UTCinvestigating

      Vi undersøger et problem med Recording, Loom AI, Authentication, og fakturering, der påvirker nogle Loom Cloud kunder. Vi vil give flere detaljer inden for den næste time.

    2. 27. oktober 2025 kl. 16.33 UTCinvestigating

      Vi fortsætter med at undersøge problemet med Recording, Loom AI, Authentication, og fakturering, der påvirker nogle Loom Cloud kunder. Vi undersøger og vil sende opdateringer på 17: 35 UTC eller tidligere.

    3. 27. oktober 2025 kl. 17.34 UTCinvestigating

      Vi fortsætter med at undersøge problemet med Recording, Loom AI, Authentication, og fakturering, der påvirker nogle Loom Cloud kunder. Vi vil sende en anden opdatering på 18: 35 UTC eller før, som tingene skrider frem.

    4. 27. oktober 2025 kl. 18.32 UTCinvestigating

      Vi fortsætter med aktivt at undersøge problemet med Recording, Loom AI, Authentication, og fakturering, der påvirker nogle Loom Cloud kunder. Vi sætter pris på din tålmodighed. Vi vil sende en anden opdatering på 19: 35 UTC eller før, som tingene skrider frem.

    5. 27. oktober 2025 kl. 19.06 UTCmonitoring

      Vi har identificeret den grundlæggende årsag til problemet med Recording, Loom AI, Authentication, og fakturering, som påvirker nogle Loom Cloud kunder. Vi har gennemført lempelser for at løse problemet og overvåger nu nøje. Vi vil give en anden opdatering på 20: 00 UTC eller før, som tingene skrider frem.

    6. 27. oktober 2025 kl. 19.59 UTCmonitoring

      Vi er aktivt at gennemføre yderligere lempelser for at løse problemet påvirker Recording, Loom AI, Authentication, og fakturering for nogle Loom Cloud kunder. Vi vil fortsætte med at overvåge tæt og give en anden opdatering på 21: 00 UTC eller tidligere, som tingene skrider frem.

    7. 27. oktober 2025 kl. 21.06 UTCmonitoring

      Vi har gennemført yderligere lempelser for at løse problemet påvirker Recording, Loom AI, Authentication, og fakturering for nogle Loom Cloud kunder. Vi ser gode tegn på genopretning, og alle tjenester er operationelle. Vi vil fortsætte med at overvåge tæt og give en anden opdatering på 22: 00 UTC eller tidligere, som tingene skrider frem.

    8. 27. oktober 2025 kl. 22.00 UTCresolved

      På 27 okt 2025, mellem 12: 30 og 22: 15 UTC, oplevede vi forringet ydeevne påvirker registrering, Loom AI, Authentication, og fakturering tjenester for nogle Loom kunder. Vi har indsat en løsning for at mindske problemet og har bekræftet, at tjenesterne er kommet sig. De betingelser, der forårsager problemet er blevet behandlet, og vi arbejder aktivt på en permanent rettelse. Problemet er løst, og tjenesten fungerer normalt. Når vi er færdige med vores interne undersøgelse, vil vi offentliggøre en mere detaljeret post mortem af, hvad der gik galt, sammen med skridt, vi tager for at forhindre dette i at ske igen i fremtiden. Bemærk: Som et resultat af denne hændelse, nogle Looms registreret i perioden med forringet ydeevne kan have opholdt sig i en "upload" tilstand. Disse videoer kan ikke erstattes, og er blevet arkiveret fra brugernes biblioteker.

    9. 21. november 2025 kl. 19.49 UTCpostmortem

      # # # Oversigt Den 27. oktober 2025 mellem 12: 30 og 20: 55 UTC, Loom blev væsentligt nedbrudt for alle kunder. Brugerne oplevede også korte nedbrydningsperioder den 28. oktober 2025 fra 20: 26 til 20: 33 UTC og 30 oktober 2025 19: 22 til 19: 27 UTC. Under hændelsen, brugere oplevede problemer med intermitterende eller svigtende afspilning, optagelser, udskrift generation, problemer logge ind, og generelle fejl eller langsommelighed på tværs af tjenesten. Vores overvågning viser, at mellem 20% og 80% af brugernes interaktioner var svigtende i disse perioder, med fiaskoer vokser i den senere halvdel af hændelsen. Vi ved, at udfald påvirker din produktivitet og vi undskylder til kunder, der blev påvirket under denne hændelse. Vi tager straks skridt til at forbedre Looms pålidelighed baseret på vores erfaringer fra denne hændelse. # # Analyse Fra 25. oktober 2025 viste Looms primære databaseklynge tidlige tegn på et problem. Ressourceforbruget voksede langsomt, og replikationen blev ikke fulgt op. Ingeniører blev advaret den 26 oktober 2025 og begyndte at undersøge. Vi så ingen tegn på kundernes indflydelse på dette tidspunkt, men vi gjorde identificere et problem med en genprøve baggrund job kører uden held i en løkke. Vi sendte en midlertidig fix for dette problem og planlagt at undersøge yderligere den næste dag. Mandag, 27 oktober 2025, problemet genopstod betydeligt som brug steg, og vi begyndte at observere kundernes indvirkning. Ingeniørerne overvågede sagen nøje og engagerede sig straks. Det var klart, at vores database ikke fungerede som forventet, og i løbet af de næste par timer, gjorde vi flere forsøg på at afbøde. Vi opskalerede især databaseforfatteren og to læsere for at lette ressourcepresset. Dette hjalp ikke, og brugervirkningen forblev uændret. I løbet af de næste par timer, gjorde vi flere forsøg på at genoprette normal database ydeevne. Vi rullede de seneste ændringer tilbage, optimerede individuelle forespørgsel ydeevne, tilføjede nye indekser, opdaterede database konfigurationer, og støvsugede store system og applikationstabeller. Disse ændringer gav nogle kortsigtet lettelse, men ydeevne gentagne gange forværret. Droppe vores replikation slots gjorde løse ressourcepres, men ikke forbedre den samlede forespørgsel ydeevne. Vi bemærkede så, at identiske forespørgsler var planlægning og udførelse meget hurtigere på forfatteren end på vores læser tilfælde, så vi besluttede at flytte alle spørgsmål trafik til den enkelte forfatter instans. Denne ændring afbødede straks kundens virkning. Mens denne handling løst det umiddelbare problem, var det ikke en stabil tilstand for vores service på lang sigt. I løbet af de næste par dage, gjorde vi flere forsøg på at vende tilbage til vores typiske single- forfatter, dual- læser arkitektur. Hver gang så vi de samme problemer dukke op igen, hvilket resulterede i korte nedbrydningsperioder. I mellem hvert af disse forsøg, vi gjort yderligere optimering til vores database brug, men vi var stadig ikke se den præstation, vi forventede, når tilføje tilbage vores læser tilfælde. Dette var især udfordrende, fordi vores tjenester arbejdede som forventet med en enkelt læser, og vi kun observeret denne nedbrydning, når tilføje en anden læser til klyngen. Den 31. oktober 2025 prøvede vi failover med en mindre instans størrelse, svarende til vores oprindelige arkitektur før den lodrette skalering forsøg. Dette lykkedes, genoprette Loom arkitektur til normal og fuldt afbødende hændelsen. # # Root Cause Denne hændelse kan stort set opdeles i to dele. For det første var den oprindelige nedbrydning forårsaget af flere Loom ændringer foretaget i månederne før hændelsen. For det andet, den udvidede afbødning resulterede uventet fra vores forsøg på at afbøde skalering af instans størrelser. Den første del af denne hændelse var forårsaget af en kompleks interaktion mellem flere gamle og nylige ændringer af Loom tjenester: * For år, Loom har haft en baggrund job, der bruger nested database transaktioner, et sjældent mønster i vores codebase. En forældretransaktion åbnes for hele jobbet, med børnehandler for hver arbejdsbatch. Dette job har været pålideligt, men det vil prøve igen flere gange i tilfælde af fiasko. Dette job er relativt lavt volumen og normalt hurtig, men kan kræve betydeligt databasearbejde i sjældne tilfælde. * I løbet af de sidste par måneder, for at støtte kommende funktioner og vandringer, baseline belastning og aktivitet på Looms database steg betydeligt. * Den 14. oktober 2025, også for at støtte en kommende funktion, en bred ændring til, hvordan Loom app håndterer database transaktioner. Denne ændring skulle kun træde i kraft i vores test- og iscenesættelse miljøer, men i særlige tilfælde i forbindelse med indlejrede transaktioner, det også anvendes i produktionen. * Den 25. oktober 2025, de kombinerede ændringer udløste en langsom, stigende nedbrydning af vores database. Flere store baggrund job kører kombineret og mislykkedes, forårsager forsøg på at holde en permanent åben transaktion på databasen. Denne nedbrudte replikation slots og autovakuum, der fører til tabel bloat på tværs af databasen. Den 27. oktober 2025 begyndte denne nedbrydning at påvirke vores brugere. * Efter fjernelse af de oprindelige udløsere, databasen fortsatte med at degradere og krævede betydelig manuel intervention for at stabilisere. Inddrivelse var kompliceret, fordi et forsøg på afbødning\ (lodrette instans skalering\) udløste et nyt problem. Den anden del af denne hændelse var forårsaget af vores tidligere afbødning forsøg på at skalere vores tilfælde størrelser til at håndtere den øgede belastning fra den første del: * Tidligt i hændelsen, som reaktion på øget database ressourceforbrug, vi forsøgte at afbøde ved lodret skalering vores tilfælde til større størrelser. Vi betragter generelt dette som en sikker og ofte effektiv afbødning. * Denne ændring uventet gjort databasen nedbrydning værre. Den slags nedbrydning, vi observerede fra de større tilfælde, svarede til den slags nedbrydning, vi allerede observerede i den første del af hændelsen. Efter hændelsen lærte vi direkte fra vores cloud-udbyder, at de større instans størrelser bruger en separat hukommelse arkitektur, der udfører betydeligt værre på vores arbejdsbyrde. * Denne performance forskel mellem de eksempler typer er især indlysende, når du åbner nye forbindelser. Som en del af vores undersøgelse, vi også fundet et problem med vores forbindelse pooler, der fører til overskydende forbindelse churn, når peger på en DNS load- balanceret læser endpoint. Dette forklarer, hvorfor vi kun observerede problemer, når vi tilføjer en anden læser til klyngen, og ikke med en enkelt-forfatter single- læser konfiguration. # # # * * Renovering og forbedringer * * Som en del af vores efterforskning og afbødning indsats under hændelsen, vi har allerede afsluttet flere centrale foranstaltninger til at løse lignende spørgsmål, herunder: * Optimeret transaktionshåndtering inden for vores program. * Forbedret ydeevne af høj volumen og poor-udøvende forespørgsler. * Forbedret overvågning og observerbarhed af vakuum status og tabel bloat. * Interne værktøjer forbedringer for lettere debugging * In- produkt banner til at advare brugere under hændelser. Derudover prioriterer vi følgende forbedringsaktioner: * Yderligere forbedringer af håndtering og overvågning af transaktioner. * Optimering af vores forbindelse pooling konfiguration. * Database indeks bruger optimering. * Database konfiguration forbedringer. * Forbedringer til autovakuumparametre. * Forbedringer af, hvordan vi måler og overvåger kundernes virkning. Tak. Atlantisk

    Automatisk oversat fra den officielle hændelsesopdatering.

    Atlassian Cloud Services impacted

    Startede 20. oktober 2025 kl. 07.56 UTC · 21h 28m

    Pending
    Berørte komponenter
    ViewingAuthenticationLoom AIRecording
    1. 20. oktober 2025 kl. 07.56 UTCinvestigating

      We have noticed that Atlassian Cloud services are impacted and our teams are actively investigating the same. We shall keep you informed of the progress every hour.

    2. 20. oktober 2025 kl. 08.24 UTCinvestigating

      Atlassian Cloud services are impacted and we are aware that our customers might not be able to create support tickets. Our teams are actively investigating the same. We shall keep you informed of the progress every hour.

    3. 20. oktober 2025 kl. 09.24 UTCinvestigating

      We are experiencing an outage due to some issue at the end of our public cloud provider. We are working closely with them to get this resolved or mitigated as quickly as possible. ETA of the same is not know at the moment. We shall continue to share updates every hour, if not sooner.

    4. 20. oktober 2025 kl. 09.58 UTCidentified

      We understand that our public cloud provider has identified the cause of the issue. We are starting to see some recovery and is working towards mitigation. We appreciate your patience. We shall continue to share updates every hour, if not sooner.

    5. 20. oktober 2025 kl. 11.07 UTCidentified

      We continue to work with our public cloud provider towards mitigating the issue at the earliest. We appreciate your patience. We shall continue to share updates every hour, if not sooner.

    6. 20. oktober 2025 kl. 12.06 UTCidentified

      Atlassian team is actively engaged and continues to work with our public cloud provider to mitigate this issue at the earliest. We are starting to see partial operations succeed. We appreciate your patience. We shall continue to share updates every hour, if not sooner.

    7. 20. oktober 2025 kl. 13.58 UTCidentified

      Our public cloud provider is working to mitigate this issue quickly. We are seeing some early positive indicators and are continuing to monitor. We appreciate your patience and will continue to provide updates every hour or sooner.

    8. 20. oktober 2025 kl. 14.03 UTCidentified

      We understand your pain and mitigating or fixing this issue is of utmost importance. Our public cloud provider is actively working to mitigate this issue on priority. We have been seeing partial operational success. We appreciate your patience and will continue to provide updates every hour or sooner.

    9. 20. oktober 2025 kl. 16.36 UTCidentified

      Update - Thank you for your continued patience. We understand the impact this issue is having on your operations and want to assure you that resolving this matter is our highest priority. Our public cloud provider is still actively working to mitigate this issue with urgency and while we do not have a definitive ETA at this time, we remain committed to full resolution and deeply appreciate your patience as we work through this situation. We will be providing hourly updates on this issue.

    10. 20. oktober 2025 kl. 17.27 UTCidentified

      Update - We understand the impact this issue is having on your operations and want to assure you that resolving this matter is our highest priority. Our public cloud provider is actively working to mitigate this issue with urgency. While we do not have a definitive ETA at this time, we remain committed to full resolution and deeply appreciate your patience as we work through this situation. We will continue to provide updates every hour or sooner as new information becomes available.

    11. 20. oktober 2025 kl. 17.43 UTCidentified

      We are currently aware of an ongoing incident impacting Atlassian Cloud services due to an outage with our public cloud provider, AWS. We understand the impact this issue is having on your operations and want to assure you that resolving this matter is our highest priority and we are closely monitoring the health of AWS services. While we do not have a definitive ETA at this time, we remain committed to full resolution and deeply appreciate your patience as we work through this situation. We will continue to provide updates every hour or sooner as new information becomes available.

    12. 20. oktober 2025 kl. 18.38 UTCmonitoring

      There have been no changes since our last update. We will provide our next updated by 9:00PM UTC or sooner as new information becomes available. We are currently aware of an ongoing incident impacting Atlassian Cloud services due to an outage with our public cloud provider, AWS. We understand the impact this issue is having on your operations and want to assure you that resolving this matter is our highest priority and we are closely monitoring the health of AWS services. While we do not have a definitive ETA at this time, we remain committed to full resolution and deeply appreciate your patience as we work through this situation.

    13. 20. oktober 2025 kl. 21.26 UTCmonitoring

      Monitoring - We've started seeing continued product experience improvement. While we still have a backlog of event processing, we are seeing improvements in systems operational capabilities across all products. We estimate a significant improvement with the next few hours and will continue to monitor the health of AWS services and the effects on Atlassian customers. We appreciate your continued patience and remain committed to full resolution as we work through this situation. We will post our next update in two hours.

    14. 20. oktober 2025 kl. 22.58 UTCmonitoring

      Our teams are continuing to monitor the recovery of systems across Atlassian products. This update is to inform that the Atlassian Support portal is fully operational at this time for customers that wish to contact support.

    15. 21. oktober 2025 kl. 00.03 UTCmonitoring

      Our team is now seeing recovery across all impacted Atlassian products. We are continuing to monitor for individual products that may still be processing backlogged items now that services are restored. The Atlassian Support portal is currently still displaying a message directing customers to our temporary support channel. Please note that our support portal is currently fully functional for those attempting to raise requests. We are continuing to look into this alert to remove this message. We will provide further update on our recovery status in one hour.

    16. 21. oktober 2025 kl. 01.07 UTCmonitoring

      We continue to see recovery progressing across all impacted products as backlogged items continue to be processed. The Atlassian Support portal is currently displaying a message directing customers to our temporary support channel. Please note that our support portal is currently fully functional for those attempting to raise requests. We are continuing to look into this alert to remove this message. We will provide further update on our recovery status in two hours.

    17. 21. oktober 2025 kl. 03.24 UTCmonitoring

      The issue relating to the Atlassian Support portal displaying a message to customers to use our temporary support channel has now been resolved. The Atlassian Support portal is fully functional for any ongoing support issues. With regards to other Atlassian products, we continue to see recovery continuing across all impacted products and our teams are continuing to monitor as the recovery continues. We will provide further update on our recovery status within two hours.

    18. 21. oktober 2025 kl. 05.24 UTCresolved

      Our team is now able to see full recovery across the vast majority of Atlassian products. We are aware of some ongoing issues with specific components such as migrations and JSM virtual service agents, and our team is continuing to investigate with urgency. We apologise for the inconvenience that this incident has caused and we will provide further information when the Post Incident Investigation has been completed.

    19. 24. oktober 2025 kl. 17.53 UTCpostmortem

      ### Postmortem publish date: Nov 19th, 2025 ### Summary All dates and times below are in UTC unless stated otherwise. Customers utilizing Atlassian products experienced elevated error rates and degraded performance between Oct 20, 2025 06:48 and Oct 21, 2025 04:05. The service disruptions were triggered due to an [AWS DynamoDB outage](https://aws.amazon.com/message/101925/#:~:text=1%3A50%20PM.-,DynamoDB,-Between%2011%3A48) and further affected by subsequent failures in [AWS EC2](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) and [AWS Network Load Balancer](https://aws.amazon.com/message/101925/#:~:text=service%20disruption%20event.-,Amazon%20EC2,-Between%2011%3A48) within the us-east-1 region. The incident started at Oct 20, 2025 06:48 and was detected within six minutes by our automated monitoring systems. Our teams worked to restore all core services by Oct 21, 2025 04:05. Final cleanup of backlogged processes and minor issues was completed on Oct 22, 2025. We recognize the critical role our products play in your daily operations, and we offer our sincere apologies for any impact this incident had on your teams. We are taking immediate steps to enhance the reliability and performance of our services, so that you continue to receive the standard of service you have come to trust. ### IMPACT Before examining product-level impacts, it's helpful to understand Atlassian's service topology and internal dependencies. Products such as Jira and Confluence are deployed across multiple AWS regions. The data for each tenant is stored and processed exclusively within its designated host region. This design is intentional and represents the desired operational state, as it limits the impact of any regional outage strictly to tenants in-region, in this case us-east-1. While in-scope application data is pinned to the region selected by the customer, there are times when systems need to call other internal services that may be based in a different region. If a problem occurs in the main region where these services operate, systems are designed to automatically fail over to a backup region, usually within three minutes. However, if unexpected issues arise during this failover, it can take longer to restore services. In rare cases, this could affect customers in more than one region. It’s important to note that all in-scope application data for supported products is pinned according to a customer’s chosen region. **Jira** Between Oct 20, 2025 06:48 and Oct 20, 2025 20:00, customers with tenants hosted in the us-east-1 region experienced increased error rates when accessing core entities such as Issues, Boards, and Backlogs. This disruption was caused by AWS's inability to allocate AWS EC2 instances and elevated errors in AWS Network Load Balancer \(NLB\). During this window, users may also have observed intermittent timeouts, slow page loads, and failures when performing operations like creating or updating issues, loading board views, and executing workflow transitions. Between Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced elevated failure rates when attempting to load Jira pages. This disruption was caused by the regional frontend service entering an unhealthy state during this specific time interval. Normally, the frontend service connects to the primary AWS DynamoDB instance located in the us-east-1 to retrieve the most recent configuration data necessary for proper operation. Additionally, the service is designed with a fallback mechanism that references static configuration data in the event that the primary database becomes inaccessible. Unfortunately, a latent bug existed in the local fallback path. When the frontend service nodes restarted, they were unable to load critical operational configuration data from primary or fallback sources, leading to the observed failures experienced by customers. Between Oct 20, 2025 06:48 and Oct 21, 2025 06:30, customers experienced significant delays and missing Jira in-app notifications across all regions. The notification ingestion service, which is hosted exclusively in us-east-1, exhibited an increased failure rate when processing notification messages due to AWS EC2 and NLB issues. This issue resulted in notifications being delayed - and in some cases, not delivered at all - to users worldwide. **Jira Service Management \(JSM\)** JSM was impacted similarly to Jira above, with the same timeframes and for the same reasons. Between Oct 20, 2025 08:36 and Oct 20, 2025 09:23, customers across all regions experienced significantly elevated failure rates when attempting to load JSM pages. This affected all JSM experiences including the Help Centre, Portal, Queues, Work Items, Operations, and Alerts. **Confluence** Between Oct 20, 2025 06:48 and Oct 21, 2025 02:45, customers using Confluence in the us-east-1 region experienced elevated failure rates when performing common operations such as editing pages or adding comments. The primary cause of this service degradation was the system's inability to auto-scale due to AWS EC2 issues to manage peak traffic load effectively. Though the AWS outage ended at Oct 20, 21:09, a subset of customers continued to experience failures as some Confluence web server nodes across multiple clusters remained in an unhealthy state. This was ultimately mitigated by recycling the affected nodes. To protect our systems while AWS recovered, we made a deliberate decision to enable node termination protection. This action successfully preserved our server capacity but, as a trade-off, it extended the time required for a full recovery once AWS services were restored. **Automation** Between Oct 20, 2025 06:55 and Oct 20, 2025 23:59, automation customers whose rules are processed in us-east-1 experienced delays of up to 23 hours in rule execution. During this window, some events triggering rule executions were processed out of order because they arrived later during backlog processing. This caused potential inconsistencies in workflow executions, as rules were run in the order events were received, not when the action causing the event occurred. Additionally, some rule actions failed because they depend on first-party and third-party systems, which were also affected by the AWS outage. Customers can see most of these failures in their audit logs; however, a few updates were not logged due to the nature of the outage. By Oct 21, 2025 5:30, the backlog of rule runs in us-east-1 was cleared. Although most of these delayed rules were successfully handled, there were some additional replays of events to ensure completeness. Our investigation confirmed that a few events may never have triggered their associated rules due to the outage. Between Oct 20, 2025 06:55 and Oct 20, 2025 11:20, all non-us-east-1 regional automation services experienced delays of up to 4 hours in rule execution. This was caused by an upstream service that was unable to deliver events as expected. The delivery service encountered a failure due to a cross-region dependency call to a service hosted in the us-east-1 region. Because of this dependency issue, the delivery service was unable to successfully deliver events throughout this time frame, resulting in customer-defined rules not being executed in a timely manner. **Bitbucket and Pipelines** Between Oct 20, 2025 06:48 and Oct 20, 2025 09:33, Bitbucket experienced intermittent unavailability across core services. During this period, users faced increased error rates and latency when signing in, navigating repositories, and performing essential actions such as creating, updating, or approving pull requests. The primary cause was an AWS DynamoDB outage that impacted downstream services. Between Oct 20, 2025 06:48 and Oct 20, 2025 22:46, numerous Bitbucket Pipeline steps failed to start, stalled mid-execution, or experienced significant queueing delays. Impact varied, with partial recoveries followed by degradation as downstream components re-synchronized. The primary cause was an AWS DynamoDB outage, compounded by instability in AWS EC2 instance availability and AWS Network Load Balancers. Furthermore, Bitbucket Pipelines continued to experience a low but persistent rate of step timeouts and scheduling errors due to AWS bare-metal capacity shortages in select availability zones. Atlassian coordinated with AWS to provision additional bare-metal hosts and addressed a significant backlog of pending pods, successfully restoring services by 01:30 on Oct 21, 2025. **Trello** Between Oct 20, 2025 06:48 and Oct 20, 2025 15:25, users of Trello experienced widespread service degradation and intermittent failures due to upstream AWS issues affecting multiple components, including AWS DynamoDB and subsequent AWS EC2 capacity constraints. During this period, customers reported elevated error rates when loading boards, opening cards, adding comments or attachments. **Login** Between Oct 20, 2025 06:48 and Oct 20, 2025 09:30, a small subset of users experienced failures when attempting to initiate new login sessions using SAML tokens. This resulted in an inability for those users to access Atlassian products during that time period. However, users who already had valid active sessions were not affected by this issue and continued to have uninterrupted access. The issue impacted all regions globally because regional identity services relied on a write replica located in the us-east-1 region to synchronize profile data. When the primary region became unavailable, the failover to a secondary database in another region failed, which delayed recovery. This failover defect has since been addressed. **Statuspage** Between Oct 20, 2025 06:48 and Oct 20, 2025 09:30, Statuspage customers who were not already logged in to the management portal were unable to log in to create or update incident statuses. This impact was restricted only to users who were not already logged in at the time. The root cause was the same as described in the Login section above, and it was resolved by the same remediation steps. ### REMEDIAL ACTION PLAN & NEXT STEPS We have completed the following critical actions designed to help prevent cross-region impact from similar issues: * Resolved the code defect in the fallback option to ensure that Jira Frontend Services in other regions remain unaffected during a region-wide outage. * Fixed the issue that prevented timely failover of the identity service which impacted new login sessions. * Resolved the code defect so that delivery services in unaffected regions remain operational during region-wide outages. Additionally, we are prioritizing the following improvement actions: * Implement mitigation strategies to strengthen resilience against region-wide outages in the notification ingestion service. Although disruptions to our cloud services are sometimes unavoidable during outages of the underlying cloud provider, we continuously evaluate and improve test coverage to strengthen resilience of our cloud services against these issues. We recognize the critical importance of our products to your daily operations and overall productivity, and we extend our sincere apologies for any disruptions this incident may have caused your teams. If you were impacted and require additional details for internal post-incident reviews, please reach out to your Atlassian support representative with affected timeframes and tenant identifiers so we can correlate logs and provide guidance. Thanks, Atlassian Customer Support

    Issue with Loom Meeting Recordings in Zoom

    Startede 12. september 2025 kl. 20.43 UTC · 1h 31m

    OutageStørre hændelse
    Berørte komponenter
    Recording
    1. 12. september 2025 kl. 20.43 UTCmonitoring

      From 5:03 AM ET to 4:15 PM ET, some customers were unable to record Zoom meetings using Loom Meeting Recordings. Attempts made during this time may appear in your library but will not be playable, as no recording was captured. Unfortunately, these recordings cannot be recovered. We have released a fix and we are monitoring recovery.

    2. 12. september 2025 kl. 22.14 UTCresolved

      The issue has been resolved and the service is operating normally.

    Issues with Recording on Loom Chrome Extension

    Startede 8. september 2025 kl. 21.46 UTC · 0m

    Pending
    1. 8. september 2025 kl. 21.46 UTCresolved

      From 5:20AM to 3:45PM UTC today some customers using the Loom Chrome Extension experienced issues with recording. Looms recorded during this time may show up in the library but will not be playable. Unfortunately we are unable to recover these videos. If you are still experiencing this issue please make sure you are recording with extension version 5.5.121.

    Loom Intermittent Issues

    Startede 15. august 2025 kl. 19.35 UTC · 24m

    OutageStørre hændelse
    Berørte komponenter
    ViewingAuthenticationLoom AIRecording
    1. 15. august 2025 kl. 19.35 UTCidentified

      We are investigating reports of issues for Loom customers. Including names showing as IDs. We will provide more details once we identify the cause.

    2. 15. august 2025 kl. 19.50 UTCmonitoring

      We have identified the cause of the issues and we are monitoring recovery.

    3. 15. august 2025 kl. 19.58 UTCresolved

      Between 18:45 and 19:35 UTC we experienced degraded functionality for Loom. The issue has been resolved and the service is operating normally.

    Customers unable to checkout with loom monthly plans

    Startede 14. april 2025 kl. 19.07 UTC · 27m

    Pending
    1. 14. april 2025 kl. 19.07 UTCidentified

      Customers are unable to choose a monthly plan when upgrading or purchasing from loom.com. We are investigating this issue.

    2. 14. april 2025 kl. 19.30 UTCmonitoring

      A fix has been implemented and we are monitoring the results

    3. 14. april 2025 kl. 19.34 UTCresolved

      This issue is now resolved and customers can checkout as expected.