Cycode driftsforstyrrelser

1. 27. oktober 2026 kl. 10.06 UTCinvestigating

   * * Oversigt * * Nogle Bitskovl Cloud-integreringer, der bruger OAuth afbrudt efter Bitskovls autentificering service returnerede fejl den 27 oktober 2026, på 03: 45 UTC. * * Indvirkning * * For berørte integreringer, kan Cycode ikke få adgang til Bitspande. Scans, lagersyncs, og begå statuer for disse arbejdsrum stoppe indtil integrationen er godkendt igen. Integrationer, der bruger app adgangskoder, API tokens, eller workspace adgang tokens er ikke påvirket. * * Sidste opdatering * * Vores undersøgelse viser, at Bitspande udstedt nye akkreditiver for disse integreringer, men ikke levere dem til Cycode, fordi dens service returneret en fejl. Bitskovl ikke længere accepterer de tidligere legitimationsoplysninger, så Integrationerne kan ikke komme sig automatisk. Vi rapporterer spørgsmålet til Atlantian. * * Krævet handling * * Hvis din Bitskovl integration viser som afbrudt, tillade det igen i Cycode konsol under [Indstillinger > Integrationer > Bitskovl]. Cycode fortsætter fra hvor det stoppede, og ingen andre ændringer er nødvendige. Vi vil sende en opdatering, når vi har flere oplysninger.

2. 27. oktober 2026 kl. 10.46 UTCmonitoring

   Vi har identificeret enhver berørt integration og kontakter nu deres brugere direkte. En integration begynder at virke igen, så snart brugeren tillader det igen i Cycode-konsollen under [Indstillinger > Integrationer > Bitspande]. Vi rapporterede Bitbuck fejl til Atlantis og vil sende en opdatering, når vi har mere information.

3. 27. oktober 2026 kl. 12.51 UTCresolved

   Alle berørte Bitbucket Cloud integreringer blev identificeret, og deres brugere modtaget instruktioner om at tillade dem igen. Integrationer, der blev godkendt igen fungerer normalt. Den grundlæggende årsag var en Bitbucket service fejl på 27 oktober 2026, på 03: 45 UTC, som invaliderede legitimation af nogle integreringer. Vi delte detaljerne med Atlantis for deres efterforskning.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 20. oktober 2026 kl. 09.28 UTCinvestigating

   Vi har identificeret en potentiel årsag til login flow spørgsmål og er ved at undersøge yderligere.

2. 20. oktober 2026 kl. 09.54 UTCinvestigating

   Vi har løst problemet med login flow i EU-regionen.

3. 20. oktober 2026 kl. 10.04 UTCmonitoring

   Problemet er løst, og vi fortsætter med at overvåge systemet for at sikre stabilitet.

4. 20. oktober 2026 kl. 15.43 UTCresolved

   Hændelsen er blevet fuldstændig løst, og vi ser ingen yderligere spørgsmål.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 18. oktober 2026 kl. 13.10 UTCinvestigating

   Vi undersøger fejl i programmet relateret til PR scanning og overtrædelse belastning fejl. Vi vil holde udstationering yderligere opdateringer, når vi fandt årsagen.

2. 18. oktober 2026 kl. 13.26 UTCidentified

   Vi havde et problem med en af vores applikationsdatabaser. Databasen er tilbage til normale operationer, men er stadig nedbrudt, og vi arbejder aktivt på at fastsætte det. Platformen er tilbage til normale operationer, og overtrædelser og PR scanninger bør fungere normalt.

3. 18. oktober 2026 kl. 13.34 UTCmonitoring

   Databasen er tilbage til normale operationer. Vi overvåger aktivt, at der ikke er nogen resterende problemer.

4. 18. oktober 2026 kl. 14.40 UTCresolved

   Hændelsen er blevet fuldstændig løst, og vi ser ingen yderligere spørgsmål.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. oktober 2026 kl. 12.56 UTCmonitoring

   * * Overvågning * *: scanner API (US region) Tidligere i dag vores alarmsystem opdaget, at tjenesten bag scanningerne API var genstarter oftere end forventet, hvilket forårsagede nogle anmodninger til at mislykkes i en kort periode. Vi øgede hukommelsen til rådighed for tjenesten, og den har været stabil siden. Vi holder tjenesten under nøje observation, mens vi afslutter en permanent forbedring.

2. 13. oktober 2026 kl. 13.01 UTCresolved

   * * Resolved * *: Kort opbremsning af scanningerne API (US region) Den 13. oktober 2026, mellem 07: 58 og 08: 28 UTC, nogle anmodninger til scanningerne API i den amerikanske region mislykkedes eller var langsom. Scan sider i Cycode UI og Cycode CLI kan have vist midlertidige fejl, og nogle pull request scanninger ankom et par minutter senere end normalt. Vi øgede hukommelsen til rådighed for tjenesten, som helt løst problemet på 08: 34 UTC. Alle queued scanninger afsluttet kort tid efter, og ingen data blev tabt. Vi har identificeret årsagen, og en permanent forbedring er under revision.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. oktober 2026 kl. 08.30 UTCinvestigating

   GitLab oplever i øjeblikket en serviceforstyrrelse, der kan påvirke Cycode PR scanning og integration konnektivitet. Emnet stammer fra GitLab infrastruktur og er uden for Cycode kontrol. Vi overvåger situationen og vil levere opdateringer som GitLab arbejder på at genoprette normal service. For mere information, se GitLab status side: [https: / / status.gitlab.com / page / event / 5b36dc6502d06804c08349f7 / 6acdd94de3aa7005ae52c614] (https: / / status.gitlab.com / page / event / 5b36dc6502d06804c08349f7 / 6acd94a7005ae52c614 "https: / status.gitlab.com / page / event / 5b36dc6502d06804c08349f7 / 6acd94943aw / 6acd943aw / 6acd3aaw)"

2. 13. oktober 2026 kl. 08.47 UTCmonitoring

   GitLab har flyttet hændelsen, der påvirker PR scanning og integration forbindelse til overvågningsfasen. GitLab har implementeret et fix og overvåger resultaterne. Vi fortsætter med at overvåge indvirkningen på Cycode-integration og vil om nødvendigt give yderligere opdateringer. For mere information, se GitLab status side: [https: / / status.gitlab.com / page / event / 5b36dc6502d06804c08349f7 / 6acdd94de3aa7005ae52c614] (https: / / status.gitlab.com / page / event / 5b36dc6502d06804c08349f7 / 6acd94a7005ae52c614 "https: / status.gitlab.com / page / event / 5b36dc6502d06804c08349f7 / 6acd94943aw / 6acd943aw / 6acd3aaw)"

3. 13. oktober 2026 kl. 11.27 UTCresolved

   GitLab har løst hændelsen, der påvirker PR scanning og integration konnektivitet

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. oktober 2026 kl. 14.22 UTCinvestigating

   Holdet fortsætter med at arbejde med AWS, som eskalerede spørgsmålet internt. Parallelt, vi arbejder på at genoprette funktionalitet ved at flytte til en anden database. Enhver blokeret pull-anmodninger, der venter på Cycode status, kan fjernes ved at fjerne Cycode scanninger fra forventede kontroller direkte i din SCM (Source Code Management). Ræk ud til din Cycode repræsentant for at hjælpe med at strømline processen.

2. 7. oktober 2026 kl. 14.22 UTCinvestigating

   AWS har bekræftet, at den berørte PostgreSQL instans er i øjeblikket i en intern recovery state. Den forventede Multi- AZ failover opstod ikke som designet, og AWS er aktivt undersøge hvorfor. Sideløbende hermed fortsætter vi arbejdet med at genoprette de berørte tjenester ved hjælp af en alternativ databasestil at fremskynde inddrivelse

3. 7. oktober 2026 kl. 14.22 UTCinvestigating

   Vi ser, at databasen genopretter sin operationelle kapacitet. Vi ser først Pull Request scanninger bliver behandlet. Vi overvåger systemet og øger gennemstrømningen.

4. 7. oktober 2026 kl. 14.22 UTCinvestigating

   Databasen er stadig fuldt operationel. Vi arbejder på at øge proceshastighed ud over regelmæssig til at behandle alle backlogs så hurtigt som muligt.

5. 7. oktober 2026 kl. 14.22 UTCinvestigating

   Vi fortsætter med at undersøge en større nedbrydning i den amerikanske platform forårsaget af PostgreSQL forbindelse udmattelse. Kunder kan opleve langsomme svartider, forhøjede 500 fejl, og langsommere PR-workflows og CLI scanner. Vi har reduceret databasebelastningen på tværs af flere tjenester og startet en RDS fejl. Holdet arbejder aktivt på at genoprette normal præstation.

6. 7. oktober 2026 kl. 14.22 UTCinvestigating

   Vi har bemærket forringet ydeevne i prod- os Flows som Pull Request eller CLI scanning kan være langsommere end normalt

7. 7. oktober 2026 kl. 14.22 UTCinvestigating

   Holdet arbejder aktivt med AWS og undersøge, hvad der synes at være en database failover spørgsmål, der påvirker det amerikanske miljø. Vi deler en ny opdatering, så snart vi har flere oplysninger.

8. 7. oktober 2026 kl. 14.22 UTCinvestigating

   Den amerikanske platform forbedres efter tidligere RDS / PostgreSQL tilslutning udmattelse. AWS har bekræftet, at den oprindelige PostgreSQL instans er vendt tilbage til en operationel tilstand, og vi ser PR scanninger bliver behandlet igen. Den vigtigste resterende nedbrydning er forsinket GitHub-drevet behandling på grund af en stor webhook backlog, som fortsætter med at dræne. Vi vil fortsætte med at overvåge inddrivelse og give en anden opdatering som behandling vender tilbage til normal

9. 7. oktober 2026 kl. 14.22 UTCinvestigating

   Systemet er tilbage til at være fuldt operationelt

10. 7. oktober 2026 kl. 14.22 UTCresolved

    (2 / 2) â €¢Paused de arbejdsbyrder, der var at skabe store mængder af kortlivede data operationer, at reducere databasebelastning, mens forsinkede begivenheder ryddet. • Scannede de pull anmodninger, der blev savnet under hændelsen. * * 4b. • Ændre hvor store partier af data der skrives for at reducere databasebelastningen. • Flytte vores højeste-volumen arbejdsbyrde til sin egen dedikerede database, så et problem der ikke kan påvirke resten af platformen. • Tilføj advarsler og dybere overvågning for brug af databaseforbindelse og databasesundhed. • Giv hver tjeneste sine egne særlige databaseoplysninger. • Behandle indgående begivenheder mere effektivt at fremskynde inddrivelse efter en afbrydelse. • Forbedre overvågningen af behandlingsforsinkelser og indberetninger om interne hændelser. • Gennemgå databasekapacitet og ydelsesindstillinger for at tilføje mere headroom.

11. 7. oktober 2026 kl. 14.22 UTCresolved

    (1 / 2) * * 1. Oversigt * * Den 5. oktober 2026, starter på 15: 55 IDT, kunder på vores amerikanske platform så langsomme svar, intermitterende fejl, og forsinkelser i pull anmodning kontrol og CLI scanninger. Nogle kunder, hvis datalagre kræver Cycode pull request checks kunne ikke fusionere, før scanningen genoptaget. Problemet startede, da en baggrundsvedligeholdelsesproces i vores primære database faldt bagud og stoppede med at fuldføre, og databasen stoppede med at gemme nye data. Genoprettelse service tog flere timer, fordi standby-databasen først skulle behandle en stor efterslæb af ændringer. Databasen var tilbage og platformen var tilgængelig igen ved 19: 43 IDT. Forsinket behandling derefter indhentet, og hændelsen blev løst kl 23: 24 IDT. Træk anmodninger, der blev overset under hændelsen blev scannet. * * 2. Nøgletidslinje (IDT) * * • * * 5. oktober 2026, 12: 55 En rutinemæssig databasevedligeholdelsesproces begynder at køre meget langsommere end normalt. Ingen kundepåvirkning endnu. * * 5. oktober 2026, 14: 53 IDT * *: Den næste vedligeholdelsescyklus starter og er ikke færdig. * * 5. oktober 2026, 15: 55 IDT * *: Databasen holder op med at gemme nye data, og platformens ydeevne nedbrydes. * * 5. oktober 2026, 16: 03 IDT * *: Databasen når sin forbindelsesgrænse. Kunder begynder at se fejl. 5. oktober 2026, 16: 21 IDT * *: Hændelse anmeldt og svar team engageret. * * 5. oktober 2026, 16: 24 IDT * *: Første opdatering bogført til statussiden. * * 5. oktober 2026, 16: 49 IDT * *: Skift til standby databasen startede. * * 5. oktober 2026, 17: 00 IDT * *: Support sag åbnet med vores cloud infrastruktur udbyder. 5 oktober 2026, 18: 24 IDT * *: Alternative recovery sti startede parallelt. Workround offentliggjort for kunder blokeret af krævede pull anmodning kontrol. * * 5. oktober 2026, 19: 43 IDT * *: Databasen er tilgængelig igen, og Cycode API og Cycode Platform er tilgængelige. * * 5. oktober 2026, 19: 54 IDT * *: Træk anmodningen tilbage. * * 5. oktober 2026, 20: 20 IDT * *: Behandlingskapaciteten steg til at klare forsinkede hændelser. • * * 5. oktober 2026, 20: 45 IDT * *: Workloads med høj volumen sat på pause for at reducere databasebelastningen. * * 5. oktober 2026, 21: 56 IDT * *: Træk anmodninger savnet under hændelsen identificeret og scannet. * * 5. oktober 2026, 23: 09 IDT * *: Alle tjenester er fuldt operationelle. * * 5. oktober 2026, 23: 24 IDT * *: Hændelsen løst. * * 3. Rodårsag * * Vores database kører en rutine baggrund proces, der regelmæssigt gemmer nylige ændringer til permanent opbevaring. To betingelser bidrog til, at processen aftog: • * * High- volumen kortlivede dataoperationer: * * nogle af vores behandling workloads var konstant at skabe og fjerne et stort antal kortlivede datastrukturer. • * * En forsinket baggrundssynkronisering: * * en datasynkroniseringsproces var faldet langt bagefter, hvilket forhindrede databasen i at rydde op efter sig selv. Vedligeholdelses processen bremsede og til sidst stoppede med at fuldføre. Databasen kunne så ikke længere gemme nye data, og anmodninger begyndte at kø. Vores tjenester genprøvede disse anmodninger og åbnede mange nye forbindelser, som brugte databasens forbindelseskapacitet. Kunderne så dette som fejl og langsomme svar. Vi skiftede til vores database. Før det kunne betjene trafikken, var det nødt til at behandle alle ændringer siden sidste afsluttede vedligeholdelsescyklus, omkring fire timers aktivitet. Det forlængede udbruddet. * * 4. Handlinger taget * * • Reduceret belastning af databasen ved midlertidigt at reducere ikke-essentiel behandling. • Start en kontakt til standby databasen. • Åbnede en støttesag med vores cloud infrastruktur udbyder og arbejdede med dem på et eskaleret grundlag. • Tilberedt en alternativ recovery sti parallelt. • Delte en midlertidig workout for kunder blokeret af krævede pull request checks. • Når databasen er kommet sig, øget behandlingskapacitet til at rydde forsinkede begivenheder.

12. 7. oktober 2026 kl. 14.22 UTCinvestigating

    Sidste tilbageværende efterslæb fortsætter med at blive behandlet med en konstant hastighed. Vores skøn viser, at de sidste dele tilbage bør være fuldt behandlet i omkring 60- 90 minutter (20: 30 UTC). Vi ser de fleste pull request scanninger (60% på tidspunktet for denne opdatering) bliver afsluttet på under 15 minutter. og dette tal vokser konstant. Ud over det system ser det ud til at fungere. Vi mener, at ansøgning / UI er fuldt funktionsdygtig.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 5. oktober 2026 kl. 13.24 UTCinvestigating

   Vi har bemærket forringet ydeevne i prod- os Flows som Pull Request eller CLI scanning kan være langsommere end normalt

2. 5. oktober 2026 kl. 14.17 UTCinvestigating

   Vi fortsætter med at undersøge en større nedbrydning i den amerikanske platform forårsaget af PostgreSQL forbindelse udmattelse. Kunder kan opleve langsomme svartider, forhøjede 500 fejl, og langsommere PR-workflows og CLI scanner. Vi har reduceret databasebelastningen på tværs af flere tjenester og startet en RDS fejl. Holdet arbejder aktivt på at genoprette normal præstation.

3. 5. oktober 2026 kl. 14.29 UTCinvestigating

   Holdet arbejder aktivt med AWS og undersøge, hvad der synes at være en database failover spørgsmål, der påvirker det amerikanske miljø. Vi deler en ny opdatering, så snart vi har flere oplysninger.

4. 5. oktober 2026 kl. 15.17 UTCinvestigating

   Holdet fortsætter med at arbejde med AWS, som eskalerede spørgsmålet internt. Parallelt, vi arbejder på at genoprette funktionalitet ved at flytte til en anden database. Enhver blokeret pull-anmodninger, der venter på Cycode status, kan fjernes ved at fjerne Cycode scanninger fra forventede kontroller direkte i din SCM (Source Code Management). Ræk ud til din Cycode repræsentant for at hjælpe med at strømline processen.

5. 5. oktober 2026 kl. 16.10 UTCinvestigating

   AWS har bekræftet, at den berørte PostgreSQL instans er i øjeblikket i en intern recovery state. Den forventede Multi- AZ failover opstod ikke som designet, og AWS er aktivt undersøge hvorfor. Sideløbende hermed fortsætter vi arbejdet med at genoprette de berørte tjenester ved hjælp af en alternativ databasestil at fremskynde inddrivelse

6. 5. oktober 2026 kl. 16.58 UTCinvestigating

   Vi ser, at databasen genopretter sin operationelle kapacitet. Vi ser først Pull Request scanninger bliver behandlet. Vi overvåger systemet og øger gennemstrømningen.

7. 5. oktober 2026 kl. 17.31 UTCinvestigating

   Databasen er stadig fuldt operationel. Vi arbejder på at øge proceshastighed ud over regelmæssig til at behandle alle backlogs så hurtigt som muligt.

8. 5. oktober 2026 kl. 18.17 UTCinvestigating

   Den amerikanske platform forbedres efter tidligere RDS / PostgreSQL tilslutning udmattelse. AWS har bekræftet, at den oprindelige PostgreSQL instans er vendt tilbage til en operationel tilstand, og vi ser PR scanninger bliver behandlet igen. Den vigtigste resterende nedbrydning er forsinket GitHub-drevet behandling på grund af en stor webhook backlog, som fortsætter med at dræne. Vi vil fortsætte med at overvåge inddrivelse og give en anden opdatering som behandling vender tilbage til normal

9. 5. oktober 2026 kl. 19.06 UTCinvestigating

   Sidste tilbageværende efterslæb fortsætter med at blive behandlet med en konstant hastighed. Vores skøn viser, at de sidste dele tilbage bør være fuldt behandlet i omkring 60- 90 minutter (20: 30 UTC). Vi ser de fleste pull request scanninger (60% på tidspunktet for denne opdatering) bliver afsluttet på under 15 minutter. og dette tal vokser konstant. Ud over det system ser det ud til at fungere. Vi mener, at ansøgning / UI er fuldt funktionsdygtig.

10. 5. oktober 2026 kl. 20.09 UTCinvestigating

    Systemet er tilbage til at være fuldt operationelt

11. 5. oktober 2026 kl. 20.24 UTCresolved

    * * 1. Oversigt * * Den 5. oktober 2026, starter på 15: 55 IDT, kunder på vores amerikanske platform så langsomme svar, intermitterende fejl, og forsinkelser i pull anmodning kontrol og CLI scanninger. Nogle kunder, hvis datalagre kræver Cycode pull request checks kunne ikke fusionere, før scanningen genoptaget. Problemet startede, da en baggrundsvedligeholdelsesproces i vores primære database faldt bagud og stoppede med at fuldføre, og databasen stoppede med at gemme nye data. Genoprettelse service tog flere timer, fordi standby-databasen først skulle behandle en stor efterslæb af ændringer. Databasen var tilbage og platformen var tilgængelig igen ved 19: 43 IDT. Forsinket behandling derefter indhentet, og hændelsen blev løst kl 23: 24 IDT. Træk anmodninger, der blev overset under hændelsen blev scannet. * * 2. Nøgletidslinje (IDT) * * • * * 5. oktober 2026, 12: 55 En rutinemæssig databasevedligeholdelsesproces begynder at køre meget langsommere end normalt. Ingen kundepåvirkning endnu. * * 5. oktober 2026, 14: 53 IDT * *: Den næste vedligeholdelsescyklus starter og er ikke færdig. * * 5. oktober 2026, 15: 55 IDT * *: Databasen holder op med at gemme nye data, og platformens ydeevne nedbrydes. * * 5. oktober 2026, 16: 03 IDT * *: Databasen når sin forbindelsesgrænse. Kunder begynder at se fejl. 5. oktober 2026, 16: 21 IDT * *: Hændelse anmeldt og svar team engageret. * * 5. oktober 2026, 16: 24 IDT * *: Første opdatering bogført til statussiden. * * 5. oktober 2026, 16: 49 IDT * *: Skift til standby databasen startede. * * 5. oktober 2026, 17: 00 IDT * *: Support sag åbnet med vores cloud infrastruktur udbyder. 5 oktober 2026, 18: 24 IDT * *: Alternative recovery sti startede parallelt. Workround offentliggjort for kunder blokeret af krævede pull anmodning kontrol. * * 5. oktober 2026, 19: 43 IDT * *: Databasen er tilgængelig igen, og Cycode API og Cycode Platform er tilgængelige. * * 5. oktober 2026, 19: 54 IDT * *: Træk anmodningen tilbage. * * 5. oktober 2026, 20: 20 IDT * *: Behandlingskapaciteten steg til at klare forsinkede hændelser. • * * 5. oktober 2026, 20: 45 IDT * *: Workloads med høj volumen sat på pause for at reducere databasebelastningen. * * 5. oktober 2026, 21: 56 IDT * *: Træk anmodninger savnet under hændelsen identificeret og scannet. * * 5. oktober 2026, 23: 09 IDT * *: Alle tjenester er fuldt operationelle. * * 5. oktober 2026, 23: 24 IDT * *: Hændelsen løst. * * 3. Rodårsag * * Vores database kører en rutine baggrund proces, der regelmæssigt gemmer nylige ændringer til permanent opbevaring. To betingelser bidrog til, at processen aftog: • * * High- volumen kortlivede dataoperationer: * * nogle af vores behandling workloads var konstant at skabe og fjerne et stort antal kortlivede datastrukturer. • * * En forsinket baggrundssynkronisering: * * en datasynkroniseringsproces var faldet langt bagefter, hvilket forhindrede databasen i at rydde op efter sig selv. Vedligeholdelses processen bremsede og til sidst stoppede med at fuldføre. Databasen kunne så ikke længere gemme nye data, og anmodninger begyndte at kø. Vores tjenester genprøvede disse anmodninger og åbnede mange nye forbindelser, som brugte databasens forbindelseskapacitet. Kunderne så dette som fejl og langsomme svar. Vi skiftede til vores database. Før det kunne betjene trafikken, var det nødt til at behandle alle ændringer siden sidste afsluttede vedligeholdelsescyklus, omkring fire timers aktivitet. Det forlængede udbruddet. * * 4. Handlinger taget * * • Reduceret belastning af databasen ved midlertidigt at reducere ikke-essentiel behandling. • Start en kontakt til standby databasen. • Åbnede en støttesag med vores cloud infrastruktur udbyder og arbejdede med dem på et eskaleret grundlag. • Tilberedt en alternativ recovery sti parallelt. • Delte en midlertidig workout for kunder blokeret af krævede pull request checks. • Når databasen er kommet sig, øget behandlingskapacitet til at rydde forsinkede begivenheder. â €¢Paused de arbejdsbyrder, der var at skabe store mængder af kortlivede data operationer, at reducere databasebelastning, mens forsinkede begivenheder ryddet. • Scannede de pull anmodninger, der blev savnet under hændelsen. * * 4b. • Ændre hvor store partier af data der skrives for at reducere databasebelastningen. • Flytte vores højeste-volumen arbejdsbyrde til sin egen dedikerede database, så et problem der ikke kan påvirke resten af platformen. • Tilføj advarsler og dybere overvågning for brug af databaseforbindelse og databasesundhed. • Giv hver tjeneste sine egne særlige databaseoplysninger. • Behandle indgående begivenheder mere effektivt at fremskynde inddrivelse efter en afbrydelse. • Forbedre overvågningen af behandlingsforsinkelser og indberetninger om interne hændelser. • Gennemgå databasekapacitet og ydelsesindstillinger for at tilføje mere headroom.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. oktober 2026 kl. 14.14 UTCmonitoring

   Kl. 2: 00 EDT (18: 00 UTC), vi identificeret en betydelig belastning spike påvirker autentificering database. For at mindske problemet, vi udførte en instans opgradering. En kort afbrydelse af databaseforbindelserne kan have fundet sted under opgraderingen. Platformen er stabil, og vi overvåger fortsat situationen nøje.

2. 7. oktober 2026 kl. 14.14 UTCresolved

   Systemet er fuldt operationelt, og der er ikke observeret nogen løbende problemer. Denne hændelse er nu løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 28. september 2026 kl. 19.08 UTCmonitoring

   Kl. 2: 00 EDT (18: 00 UTC), vi identificeret en betydelig belastning spike påvirker autentificering database. For at mindske problemet, vi udførte en instans opgradering. En kort afbrydelse af databaseforbindelserne kan have fundet sted under opgraderingen. Platformen er stabil, og vi overvåger fortsat situationen nøje.

2. 28. september 2026 kl. 20.45 UTCresolved

   Systemet er fuldt operationelt, og der er ikke observeret nogen løbende problemer. Denne hændelse er nu løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. oktober 2026 kl. 14.14 UTCresolved

   Opløst

2. 7. oktober 2026 kl. 14.14 UTCinvestigating

   GitHub komponent: Træk anmodninger Original GitHub hændelse:

Automatisk oversat fra den officielle hændelsesopdatering.

1. 8. oktober 2026 kl. 08.42 UTCinvestigating

   GitHub komponent: Træk anmodninger Original GitHub hændelse:

2. 8. oktober 2026 kl. 08.42 UTCresolved

   Opløst

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. september 2026 kl. 10.36 UTCinvestigating

   GitHub komponent: Træk anmodninger Original GitHub hændelse:

2. 13. september 2026 kl. 18.53 UTCresolved

   Opløst

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. oktober 2026 kl. 14.04 UTCresolved

   MemoryDB målinger er stabile, behandlingen lag er genvundet, og systemet er nu fuldt operationelt.

2. 7. oktober 2026 kl. 14.04 UTCmonitoring

   Vi observerede en skarp spike i MemoryDB hukommelse udnyttelse i prod-os, herunder aktiv swap brug. Der er gennemført en lemlæstelse. MemoryDB målinger har været stabile siden da, og behandlingen forsinkelse er faldende hurtigt

3. 7. oktober 2026 kl. 14.04 UTCinvestigating

   Vi har bemærket forringet ydeevne i prod- os Flows som Pull Request eller CLI scanning kan være langsommere end normalt

Automatisk oversat fra den officielle hændelsesopdatering.

1. 8. september 2026 kl. 16.53 UTCinvestigating

   Vi har bemærket forringet ydeevne i prod- os Flows som Pull Request eller CLI scanning kan være langsommere end normalt

2. 8. september 2026 kl. 17.21 UTCmonitoring

   Vi observerede en skarp spike i MemoryDB hukommelse udnyttelse i prod-os, herunder aktiv swap brug. Der er gennemført en lemlæstelse. MemoryDB målinger har været stabile siden da, og behandlingen forsinkelse er faldende hurtigt

3. 8. september 2026 kl. 17.26 UTCresolved

   MemoryDB målinger er stabile, behandlingen lag er genvundet, og systemet er nu fuldt operationelt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. oktober 2026 kl. 14.14 UTCinvestigating

   Vi har bemærket forringet ydeevne i prod-eu. Performance nedbrydning påvirker al anvendelse og alle strømme (* * ligesom Pull Request eller CLI scanning * *) kan være langsommere end normalt. Vores første undersøgelse tyder på overdreven belastning af den delte database, hvilket gør læsning og skrivning til det langsommere. Holdet fortsætter med at undersøge.

2. 7. oktober 2026 kl. 14.14 UTCresolved

   Systemet er igen fuldt operationelt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 8. september 2026 kl. 09.53 UTCinvestigating

   Vi har bemærket forringet ydeevne i prod-eu. Performance nedbrydning påvirker al anvendelse og alle strømme (* * ligesom Pull Request eller CLI scanning * *) kan være langsommere end normalt. Vores første undersøgelse tyder på overdreven belastning af den delte database, hvilket gør læsning og skrivning til det langsommere. Holdet fortsætter med at undersøge.

2. 8. september 2026 kl. 10.52 UTCresolved

   Systemet er igen fuldt operationelt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. oktober 2026 kl. 14.14 UTCresolved

   GitHub komponent: Træk anmodninger Oprindelig hændelse med GitHub: https: / / stspg.io / 0xbhq84v4mt

2. 7. oktober 2026 kl. 14.14 UTCinvestigating

   GitHub komponent: Træk anmodninger Oprindelig hændelse med GitHub: https: / / stspg.io / 0xbhq84v4mt

Automatisk oversat fra den officielle hændelsesopdatering.

1. 8. oktober 2026 kl. 08.42 UTCinvestigating

   GitHub komponent: Træk anmodninger Oprindelig hændelse med GitHub: https: / / stspg.io / 0xbhq84v4mt

2. 8. oktober 2026 kl. 08.42 UTCresolved

   GitHub komponent: Træk anmodninger Oprindelig hændelse med GitHub: https: / / stspg.io / 0xbhq84v4mt

Automatisk oversat fra den officielle hændelsesopdatering.

1. 1. september 2026 kl. 15.10 UTCinvestigating

   GitHub komponent: Træk anmodninger Oprindelig hændelse med GitHub: https: / / stspg.io / 0xbhq84v4mt

2. 1. september 2026 kl. 16.05 UTCresolved

   GitHub komponent: Træk anmodninger Oprindelig hændelse med GitHub: https: / / stspg.io / 0xbhq84v4mt

Automatisk oversat fra den officielle hændelsesopdatering.

1. 8. oktober 2026 kl. 08.42 UTCinvestigating

   GitHub komponent: Træk anmodninger Den oprindelige hændelse i GitHub: https: / / stspg.io / nrbwjftcz72d

2. 8. oktober 2026 kl. 08.42 UTCresolved

   GitHub komponent: Træk anmodninger Den oprindelige hændelse i GitHub: https: / / stspg.io / nrbwjftcz72d

Automatisk oversat fra den officielle hændelsesopdatering.