Salesforce Heroku-avbrudd: Hva skjer med distribuerte applikasjoner?

Et Heroku-avbrudd betyr ikke alltid at alle distribuerte applikasjoner er helt frakoblet. Virkningen avhenger av hvilken del av plattformen som svikter: ruting, dyno-nettverk, datatjenester, distribusjonsverktøy, DNS, logging eller en integrasjon som Heroku Connect. For operatører er den raskeste måten å reagere på å identifisere det berørte laget før de starter på nytt eller endrer en sunn applikasjon.

Herokus egen hendelseshistorikk viser hvorfor denne forskjellen er viktig. 10. juni 2025 rapporterte Heroku en alvorlig plattformforstyrrelse som skapte opptil 24 timers nedetid for mange kunder. Herokus sammendrag etter hendelsen sa at en utilsiktet oppdatering av operativsystemet startet nettverkstjenester på produksjonsverter på nytt, mens en feil i rutingsoppsettet forhindret at riktige nettverksruter ble brukt på nytt. Den samme hendelsen påvirket også interne verktøy og Heroku Status-nettstedet, noe som kompliserte diagnose og kommunikasjon. Heroku uttalte at hendelsen ikke var en sikkerhetshendelse, og at ingen kundedata gikk tapt. Se det offisielle sammendraget av driftsstansen 10. juni .

Nylig, 8. mai 2026, rapporterte Heroku et tjenesteavbrudd som involverte en oppstrømsleverandør som rammet en delmengde av kunder i Nord-Amerika-regionen. Rapporterte symptomer inkluderte periodisk tilkobling, økt databaseforsinkelse og redusert ytelse involvert i tredjepartstillegg. Heroku sa senere at de migrerte berørte ressurser til en ny tilgjengelighetssone og gjenopprettet webapplikasjoner og databaser. Hendelseshistorikken er tilgjengelig på den offisielle Heroku-hendelsessiden .

Rask konsekvensmatrise: hva kan gå i stykker under et Heroku-avbrudd?

1. Kjørende applikasjoner kan mislykkes selv om koden din ikke er endret

Alle Heroku-applikasjoner kjører i administrerte containere kalt dynoer. Webdynoer mottar HTTP-trafikk, arbeidsdynoer behandler vanligvis bakgrunnsjobber, og engangsdynoer håndterer administrative oppgaver. Herokus dyno-dokumentasjon forklarer at dyno-manageren er ansvarlig for å holde disse containerne i gang.

Et plattformproblem kan derfor gjøre en tidligere funksjonsfri utgivelse utilgjengelig uten noen applikasjonsdistribusjon. Hvis vertsnettverket, dyno-manageren eller den underliggende infrastrukturen blir utilgjengelig, kan applikasjonen mislykkes selv om koden og konfigurasjonen er uendret.

Under nettverksbruddet 10. juni 2025 beskrev Heroku en nettverksfeil som kuttet utgående tilkobling for dynoer på berørte verter. Dette er en viktig driftsmessig lærdom: en feil som ser ut som en applikasjonsavhengighetsfeil kan oppstå under applikasjonslaget.

2. Rutingsfeil kan føre til 503-feil, tidsavbrudd eller periodisk suksess

Herokus HTTP-rutere mottar innkommende trafikk og videresender forespørsler til webdynamoer. Den offisielle rutingsdokumentasjonen beskriver denne veien fra lastbalanserere gjennom rutere til applikasjonsdynamoer.

Hvis bare deler av den banen er svekket, kan brukere rapportere at nettstedet «noen ganger fungerer». Én forespørsel kan nå en syk dyno mens en annen mislykkes. Dette er grunnen til at flere kontroller fra forskjellige steder er mer informative enn én nettleseroppdatering.

Herokus feilkodereferanse er nyttig når logger fortsatt er tilgjengelige. H99 og R99 er spesifikt dokumentert som plattformfeil. Andre koder kan indikere tidsavbrudd for forespørsler, avviste backend-tilkoblinger, dynoer i karantene eller problemer på applikasjonsnivå, så en H-kode i seg selv bør ikke automatisk skyldes en Heroku-omfattende hendelse.

3. Et databrudd kan føre til at appen kjører, men ikke fungerer som den skal.

En applikasjon kan ha sunne webdynamikker mens databasen er treg eller utilgjengelig. Sider som ikke krever data kan fortsatt lastes inn, mens innlogging, utsjekking, søk, skriving eller API-kall mislykkes. Dette skaper et delvis driftsavbrudd som kan se inkonsekvent ut for sluttbrukere.

Hendelsen 8. mai 2026 er et nyttig eksempel fordi Heroku rapporterte intermitterende tilkobling og økt databaseforsinkelse for berørte kunder. Heroku informerte også om at berørte kunder kunne vurdere database-failover som en avbøtende løsning under hendelsen.

Planlagt vedlikehold kan også føre til kortere avbrudd. Herokus Postgres-vedlikeholdsdokumentasjon sier at vedlikehold kan starte den tilknyttede appen på nytt, og at brukere kan se feil eller forsinkelser i flere minutter. Planlagt vedlikehold og et uventet plattformbrudd bør derfor skilles fra hverandre før eskalering.

4. Feil med Heroku Connect kan gjøre Salesforce-data foreldet uten at nettappen må tas ned

Heroku Connect synkroniserer data mellom en Salesforce-organisasjon og Heroku Postgres. I følge Heroku Connect-dokumentasjonen tilbyr tjenesten datasynkronisering i stedet for å fungere som selve webkjøringstiden.

Hvis Connect avbrytes, kan en distribuert applikasjon forbli tilgjengelig mens synkroniserte Salesforce-data slutter å oppdateres. Lesinger fra den eksisterende Postgres-kopien kan fortsatt fungere, men brukere kan se foreldede poster eller forsinkede skrivinger avhengig av applikasjonens tilordning og arbeidsflyt.

Herokus vedlikeholdsdokumentasjon sier at synkronisering og konfigurasjon ikke er tilgjengelige under vedlikehold av Heroku Connect, mens eksisterende data i Postgres forblir tilgjengelige. Endringer i kø beholdes, og synkroniseringen gjenopptas etterpå. Denne oppførselen er dokumentert i Heroku Connect Maintenance Operations .

5. Utplasseringsproblemer betyr ikke nødvendigvis at produksjonen er nede

Operatører bør skille «kan ikke distribuere» fra «applikasjon utilgjengelig». Heroku kategoriserer bygg, Git-pushes, distribusjons-API-er, dashbordet, CLI og relaterte administrasjonsoperasjoner separat fra kjøretids- og datatjenester. En verktøyhendelse kan blokkere en ny utgivelse mens den nåværende kjørende utgivelsen fortsetter å betjene trafikk.

Dette skillet var synlig i Herokus hendelse 5. mai 2026, da noen kunder ikke kunne opprette anmeldelsesapper, men Heroku rapporterte eksplisitt at apper som kjører ikke ble påvirket.

Herokus dokumentasjon for utgivelsesfasen bemerker også at hvis en oppgave i utgivelsesfasen mislykkes, blir ikke den nye utgivelsen distribuert, og den nåværende utgivelsen forblir upåvirket. Under en hendelse bør du unngå å tolke en fastlåst pipeline som bevis på at den aktive appen har mislyktes.

6. DNS-hendelser kan påvirke nyopprettede apper eller domener annerledes enn eksisterende apper eller domener.

DNS er et annet tilfelle der omfanget kan være smalt. I september 2025 rapporterte Heroku et oppstrøms DNS-problem som forsinket klargjøring av DNS-poster for nye apper og domener. Den offisielle hendelsen bemerket at nyopprettede vertsnavn kunne forbli utilgjengelige inntil leverandørproblemet var løst, mens hendelsesomfanget utviklet seg til å inkludere noen DNS-feil for eksisterende applikasjoner i EU-regionen.

For en praktisk diagnose, test det eksisterende Heroku-vertsnavnet separat fra et nylig lagt til tilpasset domene. Sjekk også DNS-oppløsningen uavhengig av applikasjonens tilstand.

Hva bør du sjekke først ved mistenkt Heroku-avbrudd?

• Sjekk Salesforce Trust først. Heroku sier at Salesforce Trust ble den primære kommunikasjonskanalen for hendelser og vedlikehold 10. oktober 2025, med det eldre Heroku Status-nettstedet beholdt som en parallell sikkerhetskopi under overgangen. Se dokumentasjonen for Heroku Status .
• Bestem den berørte kategorien. Skill apper/kjøretid, datatjenester og verktøy. Dette forhindrer unødvendige programendringer under en plattformhendelse.
• Test mer enn hjemmesiden. Sjekk et statisk endepunkt, et databaseavhengig endepunkt, bakgrunnsjobber og en Salesforce-synkronisert arbeidsflyt hvis aktuelt.
• Gjennomgå feilkoder og tidsstempler. Korreler Heroku-ruter-/kjøretidsfeil med den offisielle hendelsesstarttiden.
• Bekreft om utrullinger bare er blokkert. Hvis produksjonen er i orden, unngå å tvinge frem en utrulling under en hendelse på det ustabile kontrollplanet.
• Bevar bevis. Registrer forespørselsfeil, logger, målinger, databaseforsinkelse, hendelses-ID-er og det nøyaktige UTC-vinduet.

Bør du starte dynoenhetene på nytt under et strømbrudd?

Bare når hendelsesveiledningen eller din egen dokumentasjon støtter det. Omstart kan hjelpe når en bestemt dyno har satt seg fast, men det kan også fjerne en sunn prosess eller skape ytterligere churn under en plattformomfattende hendelse.

For hendelsen 10. juni 2025 publiserte Heroku en spesifikk løsning for Private Space-applikasjoner: berørte kunder kunne stoppe individuelle dynoer én om gangen slik at de ble erstattet. Heroku advarte eksplisitt om at dette ikke garanterte full gjenoppretting mens oppstrømstjenester forble svekket, og at ikke alle dynoer skulle erstattes samtidig. Denne hendelsesspesifikke veiledningen er bevart i den offisielle utbedringsartikkelen .

Ikke generaliser denne prosedyren til alle driftsavbrudd. Hvis databasen, rutinglaget, DNS-leverandøren eller Heroku Connect er den faktiske flaskehalsen, kan det hende at det ikke oppnås noe å starte webdynamiske enheter på nytt.

Gjenopprettingen er ikke fullført når hjemmesiden først kommer tilbake

Etter at plattformtilgjengeligheten er tilbake, kan nedstrømssystemer fortsatt ta igjen det tapte. Heroku sa at etter driftsstansen i juni 2025 ble det levert forsinkede status-e-poster, synkroniseringen av Heroku Connect måtte ta igjen det tapte, og utgivelsesfasen hadde et etterslep som tok flere timer å fjerne.

For en produksjonsapplikasjon, valider gjenoppretting på tvers av hele avhengighetskjeden:

• HTTP-suksessraten og ventetiden har normalisert seg.
• Alle forventede web- og arbeidsdynamoer er i god stand.
• Lesing og skriving av databasen lykkes med normal ventetid.
• Køer og planlagte jobber behandles i stedet for å akkumuleres.
• Heroku Connect-tilordninger synkroniseres hvis de brukes.
• Distribusjoner og jobber i utgivelsesfasen fungerer som normalt.
• Logger og målinger ankommer uten unormal forsinkelse.
• Tredjepartstillegg og eksterne API-er har gjenopprettet seg.

Konklusjon

Et Salesforce Heroku-avbrudd kan påvirke distribuerte applikasjoner på flere forskjellige lag. Kjøretids- og rutingshendelser kan gjøre applikasjoner direkte utilgjengelige; datahendelser kan føre til at prosesser kjører, men ødelegger kjernefunksjoner; Connect-hendelser kan gjøre Salesforce-støttede data foreldet; og verktøyhendelser kan blokkere distribusjoner uten å påvirke utgivelsen som allerede er i produksjon.

Den beste operasjonelle responsen er derfor ikke å «starte alt på nytt». Identifiser først om feilen ligger i apper/kjøretid, data, verktøy, DNS eller en integrasjon. Sammenlign dine egne målinger med Salesforce Trust, behold bevis, følg hendelsesspesifikke retningslinjer for avbøting og bekreft alle avhengigheter etter gjenoppretting. Denne tilnærmingen reduserer risikoen for å gjøre en plattformhendelse om til din egen applikasjonshendelse.