Jira driftsforstyrrelser

1. 3. september 2026 kl. 15.57 UTCinvestigating

   Vi undersøger aktivt rapporter om en afbrydelse af tjenesten, der påvirker JIRA-kunder i USA. Vi vil dele opdateringer her som mere information er tilgængelig.

2. 3. september 2026 kl. 16.35 UTCmonitoring

   Vores hold har taget afbødende skridt til at reducere virkningen og nyttiggørelse blandt berørte kunder begyndte kl 16: 15 UTC. Vi fortsætter med at undersøge den grundlæggende årsag til problemet, og vil dele yderligere opdateringer her, da mere information er tilgængelig.

3. 3. september 2026 kl. 17.02 UTCresolved

   Den 3. september 2026 oplevede JIRA en afbrydelse, og tjenester var ikke tilgængelige for berørte brugere. Spørgsmålet er nu løst, og tjenesten fungerer normalt for alle berørte kunder.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 1. september 2026 kl. 17.09 UTCinvestigating

   Vi er aktivt at undersøge rapporter om performance nedbrydning påvirker former funktionalitet. Vi vil dele opdateringer her som mere information er tilgængelig.

2. 1. september 2026 kl. 18.27 UTCidentified

   Vi har identificeret den sandsynlige årsag til problemet, og vores hold arbejder ihærdigt på en afbødning. Berørte brugere kan opleve former, der ikke fungerer som forventet. Vi vil fortsætte med at dele yderligere opdateringer her, da mere information er tilgængelig.

3. 1. september 2026 kl. 20.33 UTCidentified

   Vores hold fortsætter med at arbejde på afbødningen. Vi vil fortsætte med at dele yderligere opdateringer her, da mere information er tilgængelig.

4. 1. september 2026 kl. 21.24 UTCmonitoring

   JIRA 's funktionsforringelse er blevet løst, og tjenesterne fungerer nu normalt for alle berørte kunder. Vi vil fortsat overvåge resultaterne nøje for at bekræfte stabiliteten.

5. 1. september 2026 kl. 21.35 UTCresolved

   Den 1. september kan nogle JIRA-brugere have oplevet funktionsforringelse, der påvirker formernes funktionalitet. Spørgsmålet er nu løst, og tjenesten fungerer normalt for alle berørte kunder.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 1. september 2026 kl. 09.12 UTCinvestigating

   Vi er klar over et problem, der påvirker overgangen til Jira Work Post. Berørte brugere kan opleve fejl, når de forsøger at overgangsproblemer. Vores hold undersøger årsagen. Vi vil give den næste opdatering om 60 minutter, eller før, hvis der er en materialeopdatering.

2. 1. september 2026 kl. 10.11 UTCmonitoring

   Vi har identificeret den grundlæggende årsag til problemet påvirker Jira arbejde element overgange og har anvendt en rettelse. Vi ser i øjeblikket tegn på bedring og vil fortsat overvåge. Vi vil levere den næste opdatering inden for den næste 1 time, eller før, hvis der er en materialeopdatering.

3. 1. september 2026 kl. 11.44 UTCresolved

   Den 1. september 2026, mellem 04: 22 UTC til 10: 59 UTC, nogle Jira brugere kan have oplevet service forstyrrelser. Spørgsmålet er nu løst, og tjenesten fungerer normalt for alle kunder.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 31. august 2026 kl. 18.28 UTCidentified

   Påvirkning

2. 1. september 2026 kl. 00.47 UTCmonitoring

   Jira Indkommende e-mails oplever forhøjede fejl, når du henter mail fra Microsoft-konti. Dette påvirker email- baseret skabelse og opdateringer af Jira arbejdsemner. Brugere kan se 500 interne server fejl, når e-mail hente forsøg opstår. Vi sporer opdateringer fra Microsoft og fortsætter med at gennemgå virkningen. Disse opdateringer er tilgængelige offentligt via https: / / status.cloud.microsoft /

3. 1. september 2026 kl. 05.18 UTCresolved

   Vi ser nu fuld bedring på tværs af Atlantiske tjenester, der er blevet påvirket, og denne hændelse er nu løst. For dem, der fortsætter med at opleve problemer i forbindelse med denne hændelse, opfordrer vi dig til at tjekke https: / / status.cloud.microsoft / som de fortsætter med at levere yderligere opdateringer om yderligere tjenester.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 27. august 2026 kl. 04.22 UTCinvestigating

   Vores hold har identificeret dette spørgsmål er også påvirke Jira Service Management. Vi vil opdatere så hurtigt som muligt.

2. 27. august 2026 kl. 04.25 UTCinvestigating

   Vi undersøger et problem med adgang til produkter, der påvirker Confluence, Jira Cloud og Jira Serivce Management kunder. Vores team undersøger omgående dette spørgsmål, og vi vil fremlægge yderligere oplysninger inden for en time eller før, hvis der foreligger oplysninger.

3. 27. august 2026 kl. 04.33 UTCidentified

   Vores hold har identificeret en mulig løsning på de problemer, der påvirker Jira Cloud, Jira Service Management og Confluence. Dette er nu ved at blive rullet ud til ramte regioner, og vi vil opdatere inden for en time, eller før, hvis yderligere oplysninger er tilgængelige.

4. 27. august 2026 kl. 04.51 UTCmonitoring

   Problemerne med at indlæse Jira Cloud, Jira Service Management og Confluence er nu i bedring. Vi vil fortsætte med at overvåge tæt for at bekræfte stabilitet og give en opdatering inden for en time, eller før der bliver mere information til rådighed.

5. 27. august 2026 kl. 05.16 UTCresolved

   Den 27. august 2026 UTC, Atlantiske produkter, herunder Jira Cloud, Jira Service Management og Confluence oplevede en afbrydelse, og tjenester var ikke tilgængelige for berørte brugere. Spørgsmålet er nu løst, og tjenesten fungerer normalt for alle berørte kunder. En offentlig post mortem for denne hændelse vil blive gjort tilgængelig på denne side, når vores fulde undersøgelse af hændelsen er afsluttet.

6. 7. september 2026 kl. 02.53 UTCpostmortem

   * * RESUMÉ * * Den 27. august 2026, mellem 03: 51 og 04: 35 UTC, Atlantiske kunder i Vesteuropa og Sydøst APAC-regioner var ude af stand til at nå Atlantisk Cloud produkter, herunder Atlantisk Analytics, Compass, Confluence, Focus, Guard, Jira, JPD, JSM, Opsgenie, Rovo Search, og Talent. Arrangementet blev udløst af en defekt kode ændring til routing lag af en af vores proxy flåder. Dette førte til HTTP 404 fejl bliver serveret til al kundetrafik gennem disse proxy flåder i Vesteuropa og Sydøst APAC regioner. Hændelsen blev opdaget inden for 1 minut af vores automatiske overvågningssystemer, og mindsket ved at rulle tilbage til den tidligere konfiguration udgivelse, som sætter proxyflåden i en kendt god tilstand. Efter proxy flåde genvundet, nogle Jira og Confluence kunder (uanset placering) modtog HTTP 503 fejl mellem 04: 33 og 04: 53 UTC som server flåder tilpasset tilstrømningen af trafik. * * IMPACT * * Den samlede virkning blev opdelt i to adskilte perioder: - Først, den 27 august 2026, mellem 03: 51 og 04: 35 UTC på Atlantisk Analytics, Compass, Confluence, Focus, Guard, Jira, JPD, JSM, Opsgenie, Rovo Search, og Talent. Hændelsen forårsagede afbrydelse af kundetrafikken fra Vesteuropa og Sydøst APAC-regioner, med HTTP 404 fejl returneret. Der var ingen indvirkning på kunde API trafik, uanset oprindelse placering. - For det andet, den 27 august 2026, mellem 04: 33 og 04: 53 UTC, nogle Jira og Confluence kunder uanset placering modtaget HTTP 503 fejl efter HTTP 404 fejl blev løst: ~ 32% af anmodninger i ap- southest-2, ~ 4% af anmodninger i eu- west-1, ~ 2,5% af anmodninger i us- west-2 og ap- southest-1, og < 1% af anmodninger i alle resterende globale regioner. * * ROOT CAUSE * * Arrangementet blev udløst af en kodeændring til en af vores proxyflåder. Der var imidlertid en fejl i den anvendte kode, som ikke blev opdaget ved manuel og automatisk afprøvning. Dette førte til en forkert konfiguration af en lejer lookup funktionalitet i proxy-niveau, hvilket førte til trafik ikke har en gyldig netværkssti, hvilket resulterer i HTTP 404 fejl bliver serveret til al kundetrafik gennem disse proxy-flåder i Vesteuropa og Sydøst APAC-regioner. Efter at proxy tier virkning genvundet, en anden periode af virkning blev forårsaget for nogle Jira og Confluence kunder. På grund af reduktionen af trafikken til Jira og Confluence af proxy flåde, Jira og Confluence service niveauer havde automatisk skaleret i antallet af servere, der betjener kundetrafik. Når proxy flåde funktionalitet blev genoprettet, den bølge af trafik overvældet Jira serviceniveau, som returnerede en forhøjet sats af HTTP 503s indtil det automatisk skaleret ud igen. * * MIDLERTIDIGE FORANSTALTNINGER Vi ved, at udfald påvirker din produktivitet. Mens vi har en række test og forebyggende processer på plads, blev dette specifikke problem ikke identificeret, fordi ændringen var relateret til en meget specifik form for kant sag, der ikke blev hentet af vores automatiserede kontinuerlig implementering suiter og manuelle test scripts. Vi prioriterer følgende forbedringstiltag for at undgå at gentage denne type hændelser: - * * Tilføjelse af yderligere foranstaltninger: * * Implementeringsrørledningen til konfigurationen af det angrebne proxy-niveau brugte et nedarvet system og havde ikke de relevante langsomme regionale udrulningsfunktioner konfigureret korrekt. Vi har allerede tilføjet de korrekte sikkerhedsforanstaltninger, og vi flytter dette til vores virksomhed standard implementering rørledning, der omfatter alle vores sikkerhedskontrol aktiveret som standard. Vi reviderer også alle netværkstjenester for at bekræfte, at de alle er på den nye standard rørledning implementering service. - * * Forbedring af serviceflådens skaleringspolitik: * * Automatisk skalering konfiguration for vores Jira og Confluence service flåder var konfigureret til at skalere i for aggressivt. Vi er grundigt gennemgå og opdatere alle de komplekse Jira og Confluence auto skalering politikker for at sikre, at dette ikke sker igen. 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.

1. 25. august 2026 kl. 08.42 UTCinvestigating

   Vi er aktivt ved at undersøge rapporter om forringelse af ydeevne resulterer i øget latency for e-mail, mobil, og slack notifikationer for Jira, JSM og Confluence. Vores hold undersøger problemet og flere oplysninger vil blive delt inden for den næste 1 time.

2. 25. august 2026 kl. 09.44 UTCinvestigating

   Vores hold har identificeret de ramte regioner og arbejder aktivt på at afbøde problemet. Vi vil levere yderligere opdateringer inden for en time, eller før, hvis vi har betydelige fremskridt at dele.

3. 25. august 2026 kl. 10.49 UTCinvestigating

   Vores hold har truffet få korrigerende foranstaltninger for at mindske problemet i en af de ramte regioner og observerer nogle forbedringer. Vi fortsætter med at overvåge situationen og vil træffe de nødvendige foranstaltninger, indtil hændelsen er fuldt ud genvundet. Vi vil levere yderligere opdateringer inden for de næste to timer, eller før, hvis vi har betydelige fremskridt at dele.

4. 25. august 2026 kl. 13.01 UTCmonitoring

   Vores hold fortsætter med at mindske problemet og observerer nogle forbedringer. Vi fortsætter med at overvåge situationen og vil træffe de nødvendige foranstaltninger, indtil hændelsen er fuldt ud genvundet. Vi vil levere yderligere opdateringer inden for de næste to timer, eller før, hvis vi har betydelige fremskridt at dele.

5. 25. august 2026 kl. 14.33 UTCresolved

   Den 25. aug 2026, nogle brugere kan have oplevet øget latency i e-mail, mobil og slap meddelelser. Spørgsmålet er nu løst, og tjenesten fungerer normalt for alle kunder.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 24. august 2026 kl. 19.22 UTCinvestigating

   Vi er aktivt undersøge rapporter om performance nedbrydning resulterer i øget latency for e-mail, mobil, og Slack meddelelser til JIRA, JSM, og Confluence. Vi vil dele opdateringer her som mere information er tilgængelig.

2. 24. august 2026 kl. 20.25 UTCinvestigating

   Vores hold har identificeret tre ramte regioner, og fortsætter med at undersøge den øgede latency påvirker e-mail, mobil, og Slack meddelelser til JIRA, JSM, og Confluence.

3. 24. august 2026 kl. 21.30 UTCidentified

   Vi har identificeret den sandsynlige årsag til problemet, og vores hold arbejder ihærdigt på en afbødning. Berørte brugere kan opleve øget latency i e-mail, mobil, og Slack meddelelser til JIRA, JSM, og Confluence. Vi vil fortsætte med at dele yderligere opdateringer her, da mere information er tilgængelig.

4. 24. august 2026 kl. 23.15 UTCresolved

   Den 24. august 2026, nogle JIRA, JSM, og Confluence brugere kan have oplevet performance nedbrydning resulterer i øget latency i e-mail, mobil, og Slack meddelelser. Spørgsmålet er løst for nyoprettede anmeldelser, og tjenesten fungerer normalt. Der kan være ældre anmeldelser, der behandles, og vi forventer, at de bliver afsluttet inden for de næste par timer.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. august 2026 kl. 11.30 UTCinvestigating

   We are investigating issues affecting your services. We are actively working to identify the cause and resolve the issue. We will provide further updates within one hour.

2. 7. august 2026 kl. 12.22 UTCmonitoring

   Some customers experienced issues accessing affected services in the Central European region. We have been able to apply the fix to mitigate the issues and we are seeing recovery. We continue to monitor the situation and should be fully recovered soon. We should be able to provide more updates in the next one hour or earlier.

3. 7. august 2026 kl. 12.52 UTCresolved

   On August 7th - 2026, between 10:27 UTC to 11:49 UTC, some users in the Central European region may have experienced service access issues. The issue has now been resolved and the service is operating normally for all the customers.

1. 7. august 2026 kl. 01.24 UTCinvestigating

   We are actively investigating reports of performance degradation affecting JIRA. Affected users may experience errors viewing issues and boards. We will share updates here as more information is available.

2. 7. august 2026 kl. 01.33 UTCinvestigating

   We are actively investigating reports of performance degradation affecting JIRA and JSM. Affected users may experience errors viewing issues and boards. We will share updates here as more information is available.

3. 7. august 2026 kl. 01.39 UTCmonitoring

   The performance degradation of JIRA has been resolved, and services are now operating normally for all affected customers. We'll continue to monitor performance closely to confirm stability.

4. 7. august 2026 kl. 01.46 UTCresolved

   On August 7, 2026, JIRA, JWM, and JSM users may have experienced performance degradation when viewing issues and boards. The issue has now been resolved, and the service is operating normally for all affected customers.

1. 20. juli 2026 kl. 20.18 UTCinvestigating

   Vi undersøger aktivt rapporter om funktionsforringelse, der påvirker Automation reglerne for Jira og Jira Service Management. Vi vil dele opdateringer her som mere information er tilgængelig.

2. 20. juli 2026 kl. 21.27 UTCinvestigating

   Vores hold fortsætter med at undersøge forsinkelser i Jira og Jira Service Management automation regel henrettelser for nogle kunder. Vi ser tegn på forbedringer, men berørte brugere kan stadig opleve forsinkelser. Vi vil dele opdateringer her som mere information er tilgængelig.

3. 21. juli 2026 kl. 04.53 UTCidentified

   Holdet har identificeret en rodårsag og efter indledende test, er nu at foretage skalering ændringer for at hjælpe med at forhindre disse regel udførelse forsinkelser. Vi vil overvåge performance i løbet af de næste 24 timer og give en opdatering på det tidspunkt eller før, hvis vi kan bekræfte, at forbedringen er på plads.

4. 22. juli 2026 kl. 00.56 UTCresolved

   Vores hold har været i stand til at bekræfte, at alle regelhenrettelser udføres normalt, og dette spørgsmål er nu løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 20. juli 2026 kl. 16.03 UTCinvestigating

   Vi undersøger aktivt rapporter om funktionsforringelse, der påvirker Automation reglerne for Jira og Jira Service Management. Vi vil dele opdateringer her som mere information er tilgængelig.

2. 20. juli 2026 kl. 16.58 UTCidentified

   Vi har identificeret den sandsynlige årsag til problemet, og vores hold arbejder ihærdigt på en afbødning. Vi ser i øjeblikket tegn på forbedringer, men berørte brugere kan opleve forsinkelser i Jira og Jira Service management Automation regel henrettelser. Vi vil fortsætte med at dele yderligere opdateringer her som mere information er tilgængelig.

3. 20. juli 2026 kl. 17.23 UTCresolved

   Den 20. juli 2026, nogle Jira og Jira Service Management brugere kan have oplevet ydeevne forringelse af automatisering regel henrettelser. Spørgsmålet er nu løst, og tjenesten fungerer normalt for alle berørte kunder.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. juli 2026 kl. 16.11 UTCinvestigating

   Vi undersøger rapporter om funktionsforringelse, der påvirker Automation for JIRA. Vi vil dele opdateringer her som mere information er tilgængelig.

2. 6. juli 2026 kl. 17.12 UTCinvestigating

   Vi fortsætter med at undersøge ydeevnenedbrydning, der påvirker Automation for JIRA i Europas regioner. Vi vil dele opdateringer her som mere information bliver tilgængelig.

3. 6. juli 2026 kl. 17.57 UTCidentified

   Vi har identificeret den sandsynlige årsag til problemet, og vores hold arbejder ihærdigt på en afbødning. Berørte brugere kan opleve funktionsforringelse, der påvirker Automation for JIRA i Europas regioner. Vi vil fortsætte med at dele yderligere opdateringer her, da mere information er tilgængelig.

4. 6. juli 2026 kl. 18.41 UTCmonitoring

   Forringelsen af JIRA 's ydeevne i Europas regioner er blevet løst, og tjenesterne fungerer nu normalt for alle berørte kunder. Vi vil fortsat overvåge resultaterne nøje for at bekræfte stabiliteten.

5. 6. juli 2026 kl. 18.52 UTCresolved

   Den 6. juli 2026, nogle brugere i Europa regioner kan have oplevet performance nedbrydning med Automation for JIRA. Spørgsmålet er nu løst, og tjenesten fungerer normalt for alle berørte kunder. Hvis du mener, at problemet vedvarer, bedes du kontakte vores Support team for yderligere hjælp og fejlfinding.

6. 27. juli 2026 kl. 06.57 UTCpostmortem

   # # Summary Den 6. jul 2026, mellem 06: 51 og 20: 17 UTC, Atlantiske kunder, der bruger cloud-produkter i europæiske (EU) regioner oplevede serviceforstyrrelser påvirker automatisering regel udførelse, brugersøgning, bruger picker, og relaterede arbejdsgange. Hændelsen begyndte, da en central identitetstjeneste oplevede databasemætning i EU 's regioner og øgede latens- og fejlrater. Mens respondenterne arbejdede på at genoprette kapaciteten, blev der anvendt en nødafbødning, som forhindrede automatiseringsregler fra adgang til identitetsendepunktet. Parallelt, den forhøjede identitet latency bidraget til en cascading fiasko i en downstream bruger søgetjeneste, nedværdigende bruger søgning og bruger picker erfaringer på tværs af flere produkter. Service blev gradvist restaureret efter yderligere database læse kapacitet blev tilføjet, nødblokken blev fjernet, og brugersøgetjenesten blev manuelt skaleret op. # Impact Hændelsen berørte kunder på tværs af flere atlantiske produkter i EU-regioner d. 6. jul 2026 mellem 06: 51 og 20: 17 UTC. - * * Nedbrydning af kerneidentitetsservice: * * Der blev observeret forhøjede intermitterende adgangshastigheder for produkter i EU 's regioner. - * * Automation regel udførelse fejl: * * automatisering regler ved hjælp af standard bruger (Automation for Jira) i Jira, Jira Service Management, og Jira Produkt Discovery i EU regioner mislykkedes med en tilladelse fejl. - * * User search and user picker failts: * * bruger søgning succesrater faldt betydeligt i EU-regioner, med bruger picker kapacitet stort set ikke tilgængelig på tværs af produkter. # Root Cause Hændelsen opstod fra en nylig konfiguration ændring, der reducerede cache levetid for en kerne identitet service. Da trafikken på EU 's arbejdsdage steg den 6. juli 2026, begyndte en større del af anmodningerne at nå frem til backing databasen direkte i stedet for at blive serveret fra cache. EU-databaserne havde ikke tilstrækkelig regional kapacitet til at absorbere den øgede belastning, og databasen CPU nåede mætning, hvilket forårsagede forhøjede intermitterende adgangshastigheder nægtet. Som en del af afbødningen blev der indført en nødspærring for at reducere belastningen af den mættede identitetstjenestedatabase og prioritere genoprettelsen af den centrale identitetstjeneste. Dette forhindrede utilsigtet automatisering regler fra at passere deres præ-udførelse tilladelse kontrol, hvilket får dem til at mislykkes. Den forlængede varighed skyldtes først og fremmest en sekundær bølge af automatiseringsregelsvigt forårsaget af den procesbegrænsende begrænsning. Parallelt hermed forårsagede den vedvarende nedbrydning øget latens og intermitterende svigt på tværs af produkter, der er afhængige af disse kontroller, og bidrog til en cascading fiasko i en downstream bruger søgetjeneste. Som følge heraf blev brugersøgnings- og brugerplukkeroplevelser stort set utilgængelige i EU-regioner, indtil tilladelsestjenesten blev genvundet, og brugersøgetjenesten blev skaleret for at genoprette kapaciteten. # # Respial Actions Plan & Next Steps Vi ved, at udfald påvirker kundernes produktivitet. Atlassian prioriterer følgende foranstaltninger for at hjælpe med at forhindre lignende hændelser i fremtiden: - * * Forbedre sikkerhedsforanstaltningerne for nødhjælp med høj virkning: * * Hårdt operationelt værktøj, så afbødning trin, der kunne deaktivere customer-vender arbejdsgange kræver yderligere gennemgang. - * * Styrke identitetskapaciteten i infrastrukturen og ændre sikkerheden: * * Gennemgå regional database størrelse og kapacitet headroom for at reducere risikoen for mætning i spidsbelastningsperioder, og forfine vurderingsprocessen for konfigurationsændringer, så downstream belastning indvirkning evalueres før produktionen udrulning. - * * Styrke modstandsdygtigheden mod kaskadebrud fra opstrøms nedbrydning: * * Revision backpressure håndtering, kredsløb bryder konfiguration, og autoskalering adfærd i tjenester, så opstrøms nedbrydning ikke forårsage bredere produkt indvirkning på tværs af brugersøgning, bruger picker, og relaterede erfaringer. - * * Hårde replay mekanismer for Automation regel svigt: * * øge modstandsdygtigheden af automatisering regler for at reducere virkningen forbundet med hændelser, der opstår i afhængigheder.. Vi anerkender, hvor kritiske pålidelige produktarbejdsgange er for vores kunder, og vi undskylder til kunder, der blev påvirket af denne hændelse. Tak. Atlantisk kundesupport

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. juli 2026 kl. 09.23 UTCinvestigating

   Vi undersøger problemer, der påvirker dine tjenester. Vi arbejder aktivt på at identificere årsagen og løse problemet. Vi vil levere yderligere opdateringer inden for en time.

2. 6. juli 2026 kl. 10.04 UTCmonitoring

   Vi har anvendt fixet med succes og ser bedring. Automatiseringskapaciteten genoprettes og bør fungere normalt fremad. Databehandlingsanmodninger, der blev indgivet i løbet af afbrydelsesperioden, blev ikke afsluttet på grund af manglende adgang til tjenesten. Vi fortsætter med at overvåge situationen og forventer fuld bedring inden for den næste time. Vi vil levere yderligere opdateringer inden for den næste time eller før.

3. 6. juli 2026 kl. 11.46 UTCinvestigating

   Vi ser stadig nogle problemer med brugersøgning, brugerplukker og aktiver i hele EU-regionen. Vi fortsætter med at undersøge situationen og vil give yderligere opdateringer i den næste time eller før.

4. 6. juli 2026 kl. 12.25 UTCmonitoring

   Vi har anvendt fixet til at mindske problemet og ser bedring. Vi fortsætter med at overvåge situationen og bør snart blive fuldt tilbagebetalt. Vi bør kunne levere flere opdateringer inden for den næste time eller tidligere.

5. 6. juli 2026 kl. 13.04 UTCresolved

   Den 6. juli 2026, mellem 06: 51 UTC til 09: 39 UTC nogle brugere kan have oplevet problemer relateret Automation, og mellem 08: 10 UTC til 11: 50 UTC nogle brugere kan have oplevet problemer relateret til brugersøgning, bruger-picker og aktiver i EU-regionen. Problemerne er nu løst, og tjenesterne fungerer normalt for alle kunder.

6. 17. juli 2026 kl. 16.59 UTCpostmortem

   # # Summary Den 6. jul 2026, mellem 06: 51 og 20: 17 UTC, Atlantiske kunder, der bruger cloud-produkter i europæiske (EU) regioner oplevede serviceforstyrrelser påvirker automatisering regel udførelse, brugersøgning, bruger picker, og relaterede arbejdsgange. Hændelsen begyndte, da en central identitetstjeneste oplevede databasemætning i EU 's regioner og øgede latens- og fejlrater. Mens respondenterne arbejdede på at genoprette kapaciteten, blev der anvendt en nødafbødning, som forhindrede automatiseringsregler fra adgang til identitetsendepunktet. Parallelt, den forhøjede identitet latency bidraget til en cascading fiasko i en downstream bruger søgetjeneste, nedværdigende bruger søgning og bruger picker erfaringer på tværs af flere produkter. Service blev gradvist restaureret efter yderligere database læse kapacitet blev tilføjet, nødblokken blev fjernet, og brugersøgetjenesten blev manuelt skaleret op. # Impact Hændelsen berørte kunder på tværs af flere atlantiske produkter i EU-regioner d. 6. jul 2026 mellem 06: 51 og 20: 17 UTC. - * * Nedbrydning af kerneidentitetsservice: * * Der blev observeret forhøjede intermitterende adgangshastigheder for produkter i EU 's regioner. - * * Automation regel udførelse fejl: * * automatisering regler ved hjælp af standard bruger (Automation for Jira) i Jira, Jira Service Management, og Jira Produkt Discovery i EU regioner mislykkedes med en tilladelse fejl. - * * User search and user picker failts: * * bruger søgning succesrater faldt betydeligt i EU-regioner, med bruger picker kapacitet stort set ikke tilgængelig på tværs af produkter. # Root Cause Hændelsen opstod fra en nylig konfiguration ændring, der reducerede cache levetid for en kerne identitet service. Da trafikken på EU 's arbejdsdage steg den 6. juli 2026, begyndte en større del af anmodningerne at nå frem til backing databasen direkte i stedet for at blive serveret fra cache. EU-databaserne havde ikke tilstrækkelig regional kapacitet til at absorbere den øgede belastning, og databasen CPU nåede mætning, hvilket forårsagede forhøjede intermitterende adgangshastigheder nægtet. Som en del af afbødningen blev der indført en nødspærring for at reducere belastningen af den mættede identitetstjenestedatabase og prioritere genoprettelsen af den centrale identitetstjeneste. Dette forhindrede utilsigtet automatisering regler fra at passere deres præ-udførelse tilladelse kontrol, hvilket får dem til at mislykkes. Den forlængede varighed skyldtes først og fremmest en sekundær bølge af automatiseringsregelsvigt forårsaget af den procesbegrænsende begrænsning. Parallelt hermed forårsagede den vedvarende nedbrydning øget latens og intermitterende svigt på tværs af produkter, der er afhængige af disse kontroller, og bidrog til en cascading fiasko i en downstream bruger søgetjeneste. Som følge heraf blev brugersøgnings- og brugerplukkeroplevelser stort set utilgængelige i EU-regioner, indtil tilladelsestjenesten blev genvundet, og brugersøgetjenesten blev skaleret for at genoprette kapaciteten. # # Respial Actions Plan & Next Steps Vi ved, at udfald påvirker kundernes produktivitet. Atlassian prioriterer følgende foranstaltninger for at hjælpe med at forhindre lignende hændelser i fremtiden: - * * Forbedre sikkerhedsforanstaltningerne for nødhjælp med høj virkning: * * Hårdt operationelt værktøj, så afbødning trin, der kunne deaktivere customer-vender arbejdsgange kræver yderligere gennemgang. - * * Styrke identitetskapaciteten i infrastrukturen og ændre sikkerheden: * * Gennemgå regional database størrelse og kapacitet headroom for at reducere risikoen for mætning i spidsbelastningsperioder, og forfine vurderingsprocessen for konfigurationsændringer, så downstream belastning indvirkning evalueres før produktionen udrulning. - * * Styrke modstandsdygtigheden mod kaskadebrud fra opstrøms nedbrydning: * * Revision backpressure håndtering, kredsløb bryder konfiguration, og autoskalering adfærd i tjenester, så opstrøms nedbrydning ikke forårsage bredere produkt indvirkning på tværs af brugersøgning, bruger picker, og relaterede erfaringer. - * * Hårde replay mekanismer for Automation regel svigt: * * øge modstandsdygtigheden af automatisering regler for at reducere virkningen forbundet med hændelser, der opstår i afhængigheder.. Vi anerkender, hvor kritiske pålidelige produktarbejdsgange er for vores kunder, og vi undskylder til kunder, der blev påvirket af denne hændelse. Tak. Atlantisk kundesupport

Automatisk oversat fra den officielle hændelsesopdatering.

1. 19. juni 2026 kl. 22.46 UTCmonitoring

   Jira og JSM kunder, der bruger Microsoft OAuth til automatisk oprettelse af Jira billetter fra e-mail var ude af stand til at læse e-mail. Dette er nu fast og funktionel for alle nye indgående e-mail-behandling. De ramte kunder i hændelsesperioden nødt til at gen- godkende Microsoft mail server til at gendanne og nedenfor er instruktionerne. For at gen- godkende en indkommende Microsoft e- mail- server: Login i Jira som Admin Vælg > System Vælg Mail > Indkommende Mail. Vælg Redigér indkommende e- mail- server. Vælg fornyet godkendelse. Indtast dine Microsoft-legitimationer for at fortsætte med at bruge din Microsoft-mailserver.

2. 26. juni 2026 kl. 05.13 UTCresolved

   Vores team har proaktivt nået ud til alle berørte organisationer, der giver nedenstående instruktioner til at gengodkende deres Microsoft mail server. Hvis du stadig oplever dette problem, skal du forsøge at fuldføre re-godkendelse som angivet nedenfor. Hvis der stadig opstår yderligere problemer, som du mener er relateret til denne hændelse, bedes du kontakte Atlantis støtte til yderligere bistand.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 10. juni 2026 kl. 04.55 UTCinvestigating

   We are investigating reports of extended delays being experienced across tasks such as processing of Incoming Emails, Notifications relating to changes or creation of Work Items, in addition to delays in processing Scheduled Triggers from Marketplace apps. Our team is looking into this with urgency and we will provide further update within one hour as our investigation continues.

2. 10. juni 2026 kl. 05.39 UTCidentified

   Our team has identified the root cause for this issue and has now deployed a fix that is rolling out across impacted products. At this time we are monitoring for the recovery of these events across Jira Service Management, Jira Cloud and Ecosystem app Scheduled Triggers. We will provide further update within one hour or when we have seen a full recovery of all task processing across these products.

3. 10. juni 2026 kl. 06.14 UTCmonitoring

   Our team has now determined that performance has returned to expected levels for those impacted by this incident. Additional products that are now known to have been impacted by this incident are Confluence, Customer Service Management, and Jira Product Discovery. These products would have seen similar impact where email notifications or processing of events may have been delayed while this incident was underway. We are now monitoring for the full recovery of performance across all products and will update when we are confident this issue is fully resolved, or within one hour, whichever is sooner.

4. 10. juni 2026 kl. 06.31 UTCresolved

   We are now confident that any of the tasks that were impacted by this incident and were delayed should now be operating as expected. We apologize for any inconvenience that this issue may have caused.

1. 9. juni 2026 kl. 05.29 UTCinvestigating

   We are investigating reports of intermittent errors and degredated performance for some Jira Service Management and Jira Cloud customers. We will provide further updates within one hour.

2. 9. juni 2026 kl. 10.21 UTCidentified

   Our team has now identified what we believe to be the root cause of this issue and is working on a fix. The expected fix for this issue will be rolling out progressively so customers should see resolutions to their issues viewing Jira boards and work items occurring over the next few hours. We will provide further update either when the update has fully completed or within 3 hours, whichever occurs earlier.

3. 9. juni 2026 kl. 10.36 UTCmonitoring

   Our team has been able to apply the fix and mitigate the issue. The services have been restored to normal operations. We will continue to actively monitor over the next 8 hours to confirm stability.

4. 9. juni 2026 kl. 18.28 UTCresolved

   The issue has now been resolved, and the service is operating normally for all affected customers.

1. 8. juni 2026 kl. 01.53 UTCinvestigating

   We are actively investigating reports of performance degradation affecting Jira and Jira Software Management customers. We'll provide an update here within the next hour, or sooner if new information becomes available.

2. 8. juni 2026 kl. 02.36 UTCidentified

   We have identified an issue causing degraded performance with Jira Software front-end experiences affecting view board, navigation, and backlog across multiple regions. Our engineering team is actively working on a resolution. We will provide an update within the next hour.

3. 8. juni 2026 kl. 02.56 UTCresolved

   On June 08 2026, between 01:30 and 02:40 UTC, users experienced degraded performance with Jira Software front-end experiences affecting view board, navigation, and backlog across multiple regions. We have implemented a fix and services have been restored to normal operation. We continue to monitor the situation closely.

1. 6. juni 2026 kl. 23.21 UTCinvestigating

   We are aware of users currently experiencing loading work items across Atlassian products in some regions. We are investigating with urgency and will provide update within one hour.

2. 7. juni 2026 kl. 00.07 UTCmonitoring

   A fix has been implemented for the issues some customers have been experiencing with creating and viewing work items in Jira. We are now monitoring for this recovery and will update shortly with further confirmation.

3. 7. juni 2026 kl. 00.13 UTCresolved

   The issues relating to viewing and creating work items in Jira should now be fully resolved.

1. 2. juni 2026 kl. 15.32 UTCinvestigating

   We are actively investigating reports of performance degradation affecting Jira and Jira Software Management customers. Some customers may experiences delays in rule execution. We'll provide an update here within the next hour, or sooner if new information becomes available.

2. 2. juni 2026 kl. 16.51 UTCresolved

   On June 2, 2026, some Jira and Jira Service Management users in the US-East region may have experienced performance degradation of automation rule executions. The issue has now been resolved, and the service is operating normally for all affected customers. Previously delayed automation rules are expected to be completed within 12 hours.

1. 1. juni 2026 kl. 07.40 UTCinvestigating

   We are investigating cases of partial-outage for Jira-software in the EU Region. We will provide more details within the next hour.

2. 1. juni 2026 kl. 08.06 UTCidentified

   We have identified an issue causing degraded performance for Jira Software, Jira Work Management, and Jira Service Management in the EU region. affected users may experience 5XX errors when accessing issues, boards, and navigation. Our engineering team is actively working on a resolution. We will provide an update within the next hour.

3. 1. juni 2026 kl. 09.07 UTCmonitoring

   We have implemented a fix for the issue causing degraded performance for Jira Software and Jira Service Management in the EU region. The impact has been mitigated, and we are actively monitoring the stability.

4. 1. juni 2026 kl. 13.23 UTCresolved

   This incident has been resolved. The issue causing degraded performance for Jira Software and Jira Service Management in the EU region has been fully mitigated. We have deployed a fix to prevent recurrence. If you continue to experience issues, please contact Atlassian Support. We apologise for the disruption and thank you for your patience.

5. 12. juni 2026 kl. 06.49 UTCpostmortem

   **SUMMARY** On June 01, 2026, between 06:54 and 08:28 UTC, Atlassian customers using Jira, Jira Service Management, and Jira Work Management were unable to view issues, boards, and backlogs, and experienced errors when performing transitions, adding comments, and navigating the product. The event was triggered by caching infrastructure autoscaling failure. The issue only impacted customers hosted in Europe. The incident was detected within 8 minutes by our automated monitoring system and mitigated by progressively scaling the caching clusters manually. The total time to resolution was 1 hour and 34 minutes due to the progressive recovery. **IMPACT** The incident caused service disruption for customers hosted in the Europe region who were unable to access core experiences across Jira Software, Jira Service Management, and Jira Work Management. **ROOT CAUSE** The root cause of the incident was a capacity constraint on our caching infrastructure in one availability zone of our EU Central cloud region. As morning traffic increased, our caching clusters attempted to scale out automatically. However, the cloud infrastructure was unable to provision additional nodes in that availability zone due to insufficient underlying capacity. Our caching infrastructure is designed to scale across multiple availability zones to ensure balanced and resilient capacity. On this occasion, a capacity constraint in one availability zone prevented the scaling operation from completing as expected. With the caching layer unable to grow to meet demand, the clusters began to experience network and/or CPU saturation and could not handle all incoming requests within the expected timeout window. Since a single user request to Jira typically involves multiple cache calls, timeouts compound rapidly. As more threads became blocked waiting on timed-out or slow cache operations, the application nodes reached its busy thread limit and began shedding load. While additional application nodes were added, these also experienced the same thread limit saturation due to the saturation of the cache layer resulting in widespread 503 service unavailable errors for customers. **REMEDIAL ACTIONS PLAN & NEXT STEPS** We know that outages impact your productivity. In addition to existing safeguards and monitoring, Atlassian is prioritizing the following actions to help prevent similar incidents in future: - **Increased minimum caching cluster size**: We have increased the minimum number of nodes in all affected caching clusters in the EU Central region. This ensures sufficient capacity headroom to handle peak traffic without relying on autoscaling, reducing the risk of a similar failure occurring. - **Change autoscaling behaviour**: We are working on improvements to our autoscaling behaviour to fall back to other availability zones when capacity is unavailable in a single zone. We apologize to customers whose services were impacted during this incident; we are taking immediate steps to improve the platform’s performance and availability. Thanks, Atlassian Customer Support