Salesforce Heroku Outage: What Happens to Deployed Applications?

A Heroku outage does not always mean every deployed application is completely offline. The impact depends on which part of the platform is failing: routing, dyno networking, data services, deployment tools, DNS, logging, or an integration such as Heroku Connect. For operators, the fastest way to respond is to identify the affected layer before restarting or changing a healthy application.

Heroku's own incident history shows why that distinction matters. On June 10, 2025, Heroku reported a severe platform disruption that created up to 24 hours of downtime for many customers. Heroku's post-incident summary said an unintended operating-system update restarted networking services on production hosts, while a routing setup flaw prevented correct network routes from being reapplied. The same incident also affected internal tools and the Heroku Status site, complicating diagnosis and communication. Heroku stated that the incident was not a security event and that no customer data was lost. See the official June 10 outage summary.

More recently, on May 8, 2026, Heroku reported a service disruption involving an upstream provider that affected a subset of customers in the North America region. Reported symptoms included intermittent connectivity, elevated database latency, and degraded performance involving third-party add-ons. Heroku later said it migrated affected resources to a new availability zone and restored web applications and databases. The incident history is available on the official Heroku incident page.

Quick impact matrix: what can break during a Heroku outage?

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.