Salesforce Heroku-nedbrud: Hvad sker der med implementerede applikationer?

Et Heroku-udfald betyder ikke altid, at alle implementerede applikationer er helt offline. Virkningen afhænger af, hvilken del af platformen der fejler: routing, dyno-netværk, datatjenester, implementeringsværktøjer, DNS, logging eller en integration som Heroku Connect. For operatører er den hurtigste måde at reagere på at identificere det berørte lag, før de genstarter eller ændrer en sund applikation.

Herokus egen hændelseshistorik viser, hvorfor denne sondring er vigtig. Den 10. juni 2025 rapporterede Heroku en alvorlig platformforstyrrelse, der skabte op til 24 timers nedetid for mange kunder. Herokus opsummering efter hændelsen viste, at en utilsigtet opdatering af operativsystemet genstartede netværkstjenester på produktionsværter, mens en fejl i routingopsætningen forhindrede, at korrekte netværksruter blev genanvendt. Den samme hændelse påvirkede også interne værktøjer og Heroku Status-webstedet, hvilket komplicerede diagnose og kommunikation. Heroku oplyste, at hændelsen ikke var en sikkerhedshændelse, og at ingen kundedata gik tabt. Se den officielle opsummering af nedbrud den 10. juni .

For nylig, den 8. maj 2026, rapporterede Heroku en serviceafbrydelse, der involverede en upstream-udbyder, som påvirkede en delmængde af kunder i Nordamerika-regionen. De rapporterede symptomer omfattede intermitterende forbindelse, forhøjet databaselatens og forringet ydeevne involverende tredjepartsudvidelser. Heroku oplyste senere, at de migrerede berørte ressourcer til en ny tilgængelighedszone og gendannede webapplikationer og databaser. Hændelseshistorikken er tilgængelig på den officielle Heroku-hændelsesside .

Hurtig effektmatrix: Hvad kan gå i stykker under et Heroku-udfald?

1. Kørende applikationer kan fejle, selv når din kode ikke er ændret

Alle Heroku-applikationer kører i administrerede containere kaldet dynoer. Webdynoer modtager HTTP-trafik, arbejdsdynoer behandler typisk baggrundsjob, og engangsdynoer håndterer administrative opgaver. Herokus dyno-dokumentation forklarer, at dyno-manageren er ansvarlig for at holde disse containere kørende.

Et platformproblem kan derfor gøre en tidligere sund udgivelse utilgængelig uden nogen applikationsudrulning. Hvis værtsnetværk, dyno-manageren eller den underliggende infrastruktur bliver utilgængelig, kan applikationen fejle, selvom dens kode og konfiguration er uændret.

Under netværksafbrydelsen den 10. juni 2025 beskrev Heroku en netværksfejl, der afbrød den udgående forbindelse for dynamoer på berørte værter. Dette er en vigtig operationel lektie: en fejl, der ligner en applikationsafhængighedsfejl, kan opstå under applikationslaget.

2. Routingfejl kan forårsage 503'ere, timeouts eller periodisk succes

Herokus HTTP-routere modtager indgående trafik og videresender anmodninger til webdynamoer. Den officielle routingdokumentation beskriver denne sti fra load balancers gennem routere til applikationsdynamoer.

Hvis kun en del af den sti er forringet, kan brugerne rapportere, at webstedet "nogle gange fungerer". Én anmodning kan nå en sund dyno, mens en anden fejler. Derfor er flere kontroller fra forskellige placeringer mere informative end en enkelt browseropdatering.

Herokus fejlkodereference er nyttig, når logfiler stadig er tilgængelige. H99 og R99 er specifikt dokumenteret som platformfejl. Andre koder kan indikere timeout for anmodninger, afviste backend-forbindelser, karantæne-dynamiske fejl eller problemer på applikationsniveau, så en H-kode i sig selv bør ikke automatisk skyldes en Heroku-omfattende hændelse.

3. Et dataafbrydelse kan efterlade appen kørende, men funktionelt ubrugelig

En applikation kan have sunde webdynamikker, mens dens database er langsom eller utilgængelig. Sider, der ikke kræver data, kan stadig indlæses, mens login, betaling, søgning, skrivning eller API-kald mislykkes. Dette skaber en delvis afbrydelse, der kan se inkonsekvent ud for slutbrugere.

Hændelsen den 8. maj 2026 er et nyttigt eksempel, fordi Heroku rapporterede intermitterende forbindelse og øget databaselatens for berørte kunder. Heroku oplyste også, at berørte kunder kunne overveje databasefailover som en afhjælpning under hændelsen.

Planlagt vedligeholdelse kan også skabe kortere afbrydelser. Herokus Postgres-vedligeholdelsesdokumentation siger, at vedligeholdelse kan genstarte den tilknyttede app, og at brugerne kan opleve fejl eller forsinkelser i flere minutter. Planlagt vedligeholdelse og et uventet platformsafbrydelse bør derfor skelnes, før der eskaleres.

4. Heroku Connect-fejl kan gøre Salesforce-data forældede uden at webappen skal tages ned

Heroku Connect synkroniserer data mellem en Salesforce-organisation og Heroku Postgres. Ifølge Heroku Connect-dokumentationen tilbyder tjenesten datasynkronisering i stedet for at fungere som selve webruntime-programmet.

Hvis Connect afbrydes, kan en implementeret applikation forblive tilgængelig, mens synkroniserede Salesforce-data stopper med at opdateres. Læsninger fra den eksisterende Postgres-kopi kan stadig fungere, men brugerne kan se forældede poster eller forsinkede skrivninger afhængigt af applikationens tilknytning og arbejdsgang.

Herokus vedligeholdelsesdokumentation angiver, at synkronisering og konfiguration ikke er tilgængelige under vedligeholdelse af Heroku Connect, mens eksisterende data i Postgres forbliver tilgængelige; ændringer i køen bevares, og synkroniseringen genoptages bagefter. Denne adfærd er dokumenteret i Heroku Connect Maintenance Operations .

5. Implementeringsproblemer betyder ikke nødvendigvis, at produktionen er nede

Operatører bør adskille "kan ikke implementere" fra "applikation utilgængelig". Heroku kategoriserer builds, Git pushes, implementerings-API'er, Dashboard, CLI og relaterede administrationsoperationer separat fra runtime- og datatjenester. En værktøjshændelse kan blokere en ny udgivelse, mens den aktuelt kørende udgivelse fortsat betjener trafik.

Denne forskel var synlig i Herokus hændelse den 5. maj 2026, hvor nogle kunder ikke kunne oprette anmeldelsesapps, men Heroku rapporterede eksplicit, at kørende apps ikke var påvirket.

Herokus dokumentation for udgivelsesfasen bemærker også, at hvis en opgave i udgivelsesfasen mislykkes, implementeres den nye udgivelse ikke, og den nuværende udgivelse forbliver upåvirket. Under en hændelse skal du undgå at fortolke en fastlåst pipeline som bevis på, at live-appen har fejlet.

6. DNS-hændelser kan påvirke nyoprettede apps eller domæner anderledes end eksisterende.

DNS er et andet tilfælde, hvor omfanget kan være snævert. I september 2025 rapporterede Heroku et upstream DNS-problem, der forsinkede klargøringen af ​​DNS-poster til nye apps og domæner. Den officielle hændelse bemærkede, at nyoprettede værtsnavne kunne forblive utilgængelige, indtil udbyderproblemet var løst, mens hændelsesomfanget udviklede sig til at omfatte nogle DNS-fejl for eksisterende applikationer i EU-regionen.

For en praktisk diagnose, test det eksisterende Heroku-værtsnavn separat fra et nyligt tilføjet brugerdefineret domæne. Kontroller også DNS-opløsningen uafhængigt af applikationens tilstand.

Hvad skal du kontrollere først ved en mistanke om Heroku-udfald?

• Tjek først Salesforce Trust. Heroku siger, at Salesforce Trust blev den primære kommunikationskanal for hændelser og vedligeholdelse den 10. oktober 2025, hvor det ældre Heroku Status-websted blev bevaret som en parallel backup under overgangen. Se dokumentationen for Heroku Status .
• Bestem den berørte kategori. Adskil apps/kørselstid, datatjenester og værktøjer. Dette forhindrer unødvendige applikationsændringer under en platformhændelse.
• Test mere end hjemmesiden. Tjek et statisk slutpunkt, et databaseafhængigt slutpunkt, baggrundsjob og en Salesforce-synkroniseret arbejdsgang, hvis det er relevant.
• Gennemgå fejlkoder og tidsstempler. Korrelér Heroku-router-/runtime-fejl med det officielle starttidspunkt for hændelsen.
• Bekræft om udrulninger blot er blokeret. Hvis produktionen er i orden, skal du undgå at tvinge en udrulning under en ustabil kontrolplanhændelse.
• Bevar beviser. Registrer anmodningsfejl, logfiler, metrikker, databaseforsinkelse, hændelses-ID'er og det nøjagtige UTC-vindue.

Skal man genstarte dynoer under et strømafbrydelse?

Kun når hændelsesvejledningen eller din egen dokumentation understøtter det. Genstart kan hjælpe, når en bestemt dyno sidder fast, men det kan også fjerne en sund proces eller skabe yderligere churn under en platformomfattende hændelse.

I forbindelse med hændelsen den 10. juni 2025 offentliggjorde Heroku en specifik løsning til Private Space-applikationer: berørte kunder kunne stoppe individuelle dynamoer én ad gangen, så de blev udskiftet. Heroku advarede eksplicit om, at dette ikke garanterede fuld genoprettelse, mens upstream-tjenesterne forblev forringede, og at dynamoer ikke alle skulle udskiftes samtidigt. Denne hændelsesspecifikke vejledning er bevaret i den officielle afhjælpningsartikel .

Generaliser ikke denne procedure til alle nedbrud. Hvis databasen, routinglaget, DNS-udbyderen eller Heroku Connect er den faktiske flaskehals, opnår genstart af webdynamikker muligvis intet.

Gendannelsen er ikke fuldført, når startsiden først kommer tilbage

Efter at platformtilgængeligheden vender tilbage, kan downstream-systemer stadig indhente det forsømte. Heroku sagde, at efter udbruddet i juni 2025 blev der leveret forsinkede statusmails, Heroku Connect-synkroniseringen skulle indhente det forsømte, og udgivelsesfasen havde en efterslæbning, der tog timer at afvikle.

For en produktionsapplikation, validér gendannelse på tværs af hele afhængighedskæden:

• HTTP-succesraten og latenstiden er normaliseret.
• Alle forventede web- og arbejdsdynamoer er sunde.
• Databaselæsning og -skrivning lykkes med normal latenstid.
• Køer og planlagte job behandles i stedet for at akkumuleres.
• Heroku Connect-kortlægninger synkroniseres, hvis de bruges.
• Implementeringer og job i udgivelsesfasen fungerer normalt.
• Logfiler og målinger ankommer uden unormal forsinkelse.
• Tredjepartstilføjelser og eksterne API'er er blevet gendannet.

Konklusion

Et Salesforce Heroku-nedbrud kan påvirke implementerede applikationer på flere forskellige lag. Runtime- og routinghændelser kan direkte gøre applikationer utilgængelige; datahændelser kan lade processer køre, men ødelægge kernefunktioner; Connect-hændelser kan gøre Salesforce-baserede data forældede; og værktøjshændelser kan blokere implementeringer uden at påvirke den version, der allerede er i produktion.

Den bedste operationelle reaktion er derfor ikke at "genstarte alt". Identificér først, om fejlen er i Apps/Runtime, Data, Værktøjer, DNS eller en integration. Sammenlign dine egne metrikker med Salesforce Trust, bevar beviser, følg hændelsesspecifikke afhjælpningsvejledninger, og verificer alle afhængigheder efter gendannelse. Denne tilgang reducerer risikoen for at forvandle en platformshændelse til din egen applikationshændelse.