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. Program som körs kan misslyckas även om din kod inte har ändrats

Alla Heroku-applikationer körs i hanterade containrar som kallas dynos. Webbdynos tar emot HTTP-trafik, arbetsdynos bearbetar vanligtvis bakgrundsjobb och engångsdynos hanterar administrativa uppgifter. Herokus dyno-dokumentation förklarar att dyno-hanteraren ansvarar för att hålla dessa containrar igång.

Ett plattformsproblem kan därför göra en tidigare felfri version oåtkomlig utan någon applikationsdistribution. Om värdnätverket, dynohanteraren eller den underliggande infrastrukturen blir otillgänglig kan applikationen misslyckas även om dess kod och konfiguration är oförändrade.

Under avbrottet den 10 juni 2025 beskrev Heroku ett nätverksfel som avbröt utgående anslutning för dynamostyrda system på berörda värdar. Detta är en viktig operativ lärdom: ett fel som ser ut som ett fel i applikationsberoendet kan uppstå under applikationslagret.

2. Routingfel kan orsaka 503-fel, timeouts eller intermittent framgång

Herokus HTTP-routrar tar emot inkommande trafik och vidarebefordrar förfrågningar till webbdynos. Den officiella routingdokumentationen beskriver denna väg från lastbalanserare via routrar till applikationsdynos.

Om bara en del av den sökvägen är störd kan användare rapportera att webbplatsen "ibland fungerar". En begäran kan nå en felfri dyno medan en annan misslyckas. Det är därför flera kontroller från olika platser är mer informativa än en enda webbläsaruppdatering.

Herokus felkodsreferens är användbar när loggar fortfarande är tillgängliga. H99 och R99 är specifikt dokumenterade som plattformsfel. Andra koder kan indikera timeout för begäran, vägrade backend-anslutningar, karantänsatta dynamoer eller problem på applikationsnivå, så en H-kod i sig bör inte automatiskt skyllas på en Heroku-omfattande incident.

3. Ett dataavbrott kan göra att appen körs men inte fungerar som den ska

En applikation kan ha felfria webbdynos medan dess databas är långsam eller oåtkomlig. Sidor som inte kräver data kan fortfarande laddas, medan inloggning, utcheckning, sökning, skrivningar eller API-anrop misslyckas. Detta skapar ett partiellt avbrott som kan se inkonsekvent ut för slutanvändare.

Incidenten den 8 maj 2026 är ett användbart exempel eftersom Heroku rapporterade intermittent anslutning och förhöjd databaslatens för berörda kunder. Heroku meddelade också att berörda kunder kunde överväga databas-redundans som en åtgärd under incidenten.

Planerat underhåll kan också skapa kortare avbrott. Herokus Postgres underhållsdokumentation säger att underhåll kan starta om den associerade appen och att användare kan se fel eller fördröjningar i flera minuter. Schemalagt underhåll och ett oväntat plattformsavbrott bör därför särskiljas innan man eskalerar.

4. Fel i Heroku Connect kan göra Salesforce-data inaktuell utan att webbappen behöver stängas av.

Heroku Connect synkroniserar data mellan en Salesforce-organisation och Heroku Postgres. Enligt Heroku Connect-dokumentationen tillhandahåller tjänsten datasynkronisering snarare än att fungera som själva webbkörningsmiljön.

Om Connect avbryts kan en distribuerad applikation förbli tillgänglig medan synkroniserade Salesforce-data slutar uppdateras. Läsningar från den befintliga Postgres-kopian kan fortfarande fungera, men användare kan se inaktuella poster eller fördröjda skrivningar beroende på applikationens mappning och arbetsflöde.

Herokus underhållsdokumentation anger att synkronisering och konfiguration inte är tillgängliga under Heroku Connect-underhåll medan befintliga data i Postgres förblir tillgängliga; ändringar i kö behålls och synkroniseringen återupptas efteråt. Detta beteende dokumenteras i Heroku Connect Maintenance Operations .

5. Problem med driftsättningen betyder inte nödvändigtvis att produktionen är nere

Operatörer bör separera "kan inte driftsättas" från "applikationen är inte tillgänglig". Heroku kategoriserar byggen, Git-pushes, driftsättnings-API:er, instrumentpanelen, CLI och relaterade hanteringsåtgärder separat från runtime- och datatjänster. En verktygsincident kan blockera en ny version medan den aktuella versionen fortsätter att hantera trafik.

Denna skillnad var synlig i Herokus incident den 5 maj 2026, då vissa kunder inte kunde skapa granskningsappar, men Heroku rapporterade uttryckligen att appar som kördes inte påverkades.

Herokus dokumentation för utgivningsfasen noterar också att om en uppgift i utgivningsfasen misslyckas, distribueras inte den nya versionen och den aktuella versionen förblir opåverkad. Undvik att tolka en fast pipeline som bevis på att live-appen har misslyckats under en incident.

6. DNS-incidenter kan påverka nyskapade appar eller domäner på ett annat sätt än befintliga.

DNS är ett annat fall där omfattningen kan vara snäv. I september 2025 rapporterade Heroku ett DNS-problem uppströms som försenade etableringen av DNS-poster för nya appar och domäner. Den officiella incidenten noterade att nyskapade värdnamn kunde förbli oåtkomliga tills leverantörsproblemet var löst, medan incidentens omfattning utvecklades till att inkludera vissa DNS-fel för befintliga applikationer i EU-regionen.

För en praktisk diagnos, testa det befintliga Heroku-värdnamnet separat från en nyligen tillagd anpassad domän. Kontrollera även DNS-upplösningen oberoende av applikationens tillstånd.

Vad bör du kontrollera först vid ett misstänkt Heroku-avbrott?

• Kontrollera Salesforce Trust först. Heroku säger att Salesforce Trust blev den primära kommunikationskanalen för incidenter och underhåll den 10 oktober 2025, med den äldre Heroku Status-webbplatsen behållen som en parallell säkerhetskopia under övergången. Se dokumentationen för Heroku Status .
• Fastställ vilken kategori som påverkas. Separera appar/körtid, datatjänster och verktyg. Detta förhindrar onödiga applikationsändringar under en plattformsincident.
• Testa mer än startsidan. Kontrollera en statisk slutpunkt, en databasberoende slutpunkt, bakgrundsjobb och ett Salesforce-synkroniserat arbetsflöde om tillämpligt.
• Granska felkoder och tidsstämplar. Korrelera Heroku-routerns/körtidsfel med den officiella starttiden för incidenten.
• Bekräfta om distributionerna bara är blockerade. Om produktionen är felfri, undvik att tvinga fram en distribution under en instabil kontrollplansincident.
• Bevara bevis. Registrera fel vid förfrågningar, loggar, mätvärden, databasfördröjning, incident-ID:n och det exakta UTC-fönstret.

Bör man starta om dynos under ett avbrott?

Endast när incidentvägledningen eller dina egna bevis stöder det. Omstart kan hjälpa när en viss dyno har fastnat, men det kan också ta bort en felfri process eller skapa ytterligare churn under en plattformsomfattande incident.

För incidenten den 10 juni 2025 publicerade Heroku en specifik lösning för Private Space-applikationer: berörda kunder kunde stoppa enskilda dynamoenheter en i taget så att de ersattes. Heroku varnade uttryckligen för att detta inte garanterade fullständig återställning medan uppströmstjänster förblev nedsatta och att dynamoenheter inte alla bör ersättas samtidigt. Den incidentspecifika vägledningen finns bevarad i den officiella åtgärdsartikeln .

Generalisera inte den proceduren till alla avbrott. Om databasen, routinglagret, DNS-leverantören eller Heroku Connect är den faktiska flaskhalsen, kan det hända att omstart av webbdynos inte åstadkommer någonting.

Återställningen är inte klar när startsidan först kommer tillbaka

Efter att plattformstillgängligheten återställts kan nedströmssystem fortfarande komma ikapp. Heroku sa att efter avbrottet i juni 2025 levererades försenade statusmejl, Heroku Connect-synkroniseringen var tvungen att komma ikapp och lanseringsfasen hade en eftersläpning som tog timmar att åtgärda.

För en produktionsapplikation, validera återställning över hela beroendekedjan:

• HTTP-framgångsfrekvensen och latensen har normaliserats.
• Alla förväntade webb- och arbetardynos är felfria.
• Läsningar och skrivningar till databasen lyckas med normal latens.
• Köer och schemalagda jobb bearbetas snarare än ackumuleras.
• Heroku Connect-mappningar synkroniseras om de används.
• Distributions- och lanseringsfasjobb fungerar normalt.
• Loggar och mätvärden anländer utan onormala fördröjningar.
• Tredjepartstillägg och externa API:er har återställts.

Slutsats

Ett avbrott i Salesforce Heroku kan påverka driftsatta applikationer på flera olika nivåer. Körtids- och routningsincidenter kan direkt göra applikationer oåtkomliga; dataincidenter kan lämna processer igång men förstöra kärnfunktioner; Connect-incidenter kan göra Salesforce-baserade data inaktuella; och verktygsincidenter kan blockera driftsättningar utan att påverka den version som redan är i produktion.

Den bästa operativa responsen är därför inte att "starta om allt". Identifiera först om felet finns i Appar/Körtid, Data, Verktyg, DNS eller en integration. Jämför dina egna mätvärden med Salesforce Trust, bevara bevis, följ incidentspecifika riktlinjer för begränsning och verifiera varje beroende efter återställning. Den metoden minskar risken för att förvandla en plattformsincident till en egen applikationsincident.