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.
| Affected layer | What users may see | What operators may see |
|---|---|---|
| HTTP routing | Timeouts, 503 responses, intermittent requests | Router errors, falling throughput, some dynos unreachable |
| Dyno runtime or networking | Partial or complete application failures | Dyno relocations, failed connections, H99 or related platform symptoms |
| Heroku Postgres | Slow pages, errors on data-dependent actions | High DB latency, connection failures, read-only or failover conditions |
| Heroku Connect | Salesforce-backed data may become stale | Sync lag or paused/error states while app data remains locally accessible |
| Build/release tools | Existing app may continue serving normally | New deploys, review apps, release tasks, or configuration changes may stall |
| Dashboard/API/CLI | Usually no direct user-facing effect | Management actions may be unavailable or delayed |
| DNS | New or changed hostnames may not resolve | New apps/domains inaccessible even if runtime is healthy |
| Logging/telemetry | Application may still work | Smanjena vidljivost, odgođeni zapisi, teža dijagnoza |
Sve Heroku aplikacije rade u upravljanim kontejnerima koji se nazivaju dynos. Web dynos primaju HTTP promet, radni dynos obično obrađuju pozadinske poslove, a jednokratni dynos obavljaju administrativne zadatke. Herokuova dokumentacija o dyno sustavu objašnjava da je upravitelj dyno sustava odgovoran za održavanje tih kontejnera u radu.
Problem s platformom stoga može učiniti prethodno ispravno izdanje nedostupnim bez ikakve implementacije aplikacije. Ako mrežni sustav hosta, upravitelj dyno signala ili temeljna infrastruktura postanu nedostupni, aplikacija može propasti iako su njezin kod i konfiguracija nepromijenjeni.
Tijekom prekida rada 10. lipnja 2025., Heroku je opisao mrežni kvar koji je prekinuo izlaznu vezu za dyno uređaje na pogođenim hostovima. Ovo je važna operativna lekcija: pogreška koja izgleda kao kvar ovisnosti aplikacije može nastati ispod sloja aplikacije.
Herokuovi HTTP usmjerivači primaju dolazni promet i prosljeđuju zahtjeve web dyno uređajima. Službena dokumentacija usmjeravanja opisuje ovaj put od uravnoteživača opterećenja preko usmjerivača do aplikacijskih dyno uređaja.
Ako je samo dio te putanje oštećen, korisnici mogu prijaviti da stranica „ponekad radi“. Jedan zahtjev može doći do ispravnog dinamometra, dok drugi ne uspije. Zato su višestruke provjere s različitih lokacija informativnije od jednog osvježavanja preglednika.
Herokuova referenca kodova pogrešaka korisna je kada su zapisnici dostupni. H99 i R99 su posebno dokumentirani kao pogreške platforme. Drugi kodovi mogu ukazivati na istek vremena zahtjeva, odbijene veze s pozadinom, karantenu dinamometra ili probleme na razini aplikacije, tako da se sam H-kod ne bi trebao automatski kriviti za incident na razini Herokua.
Aplikacija može imati ispravne web dinamometre dok je baza podataka spora ili nedostupna. Stranice koje ne zahtijevaju podatke mogu se i dalje učitavati, dok prijava, naplata, pretraživanje, pisanje ili API pozivi ne uspijevaju. To stvara djelomični prekid rada koji krajnjim korisnicima može izgledati nedosljedno.
Incident od 8. svibnja 2026. koristan je primjer jer je Heroku prijavio povremenu povezanost i povećanu latenciju baze podataka za pogođene korisnike. Heroku je također savjetovao da pogođeni korisnici mogu razmotriti prebacivanje baze podataka u slučaju kvara kao ublažavanje tijekom incidenta.
Planirano održavanje može stvoriti i kraće prekide. Herokuova dokumentacija o održavanju Postgresa kaže da održavanje može ponovno pokrenuti povezanu aplikaciju i da korisnici mogu vidjeti pogreške ili kašnjenja nekoliko minuta. Planirano održavanje i neočekivani prekid rada platforme stoga treba razlikovati prije eskalacije.
Heroku Connect sinkronizira podatke između Salesforce organizacije i Heroku Postgresa. Prema dokumentaciji Heroku Connecta , usluga omogućuje sinkronizaciju podataka umjesto da djeluje kao samo web okruženje.
Ako je Connect prekinut, implementirana aplikacija može ostati dostupna dok se sinkronizirani Salesforce podaci prestanu ažurirati. Čitanja iz postojeće Postgres kopije mogu i dalje funkcionirati, ali korisnici mogu vidjeti zastarjele zapise ili odgođena pisanja ovisno o mapiranju i tijeku rada aplikacije.
U dokumentaciji o održavanju Herokua navodi se da tijekom održavanja Heroku Connecta sinkronizacija i konfiguracija nisu dostupne dok postojeći podaci u Postgresu ostaju dostupni; promjene u redu čekanja se zadržavaju, a sinkronizacija se nakon toga nastavlja. To ponašanje je dokumentirano u dokumentu Heroku Connect Maintenance Operations .
Operateri bi trebali odvojiti „ne može se implementirati“ od „aplikacija nije dostupna“. Heroku kategorizira izgradnje, Git pushove, API-je za implementaciju, nadzornu ploču, CLI i povezane operacije upravljanja odvojeno od runtime i podatkovnih usluga. Incident s alatima može blokirati novo izdanje dok trenutno pokrenuto izdanje nastavlja opsluživati promet.
Ova razlika bila je vidljiva u Herokuovom incidentu 5. svibnja 2026., kada neki korisnici nisu mogli stvarati aplikacije za pregled, ali Heroku je izričito izvijestio da pokrenute aplikacije nisu bile pogođene.
Herokuova dokumentacija o fazi izdanja također napominje da ako zadatak u fazi izdanja ne uspije, novo izdanje se ne implementira, a trenutno izdanje ostaje nepromijenjeno. Tijekom incidenta izbjegavajte tumačenje zaglavljenog cjevovoda kao dokaza da je aktivna aplikacija zakazala.
DNS je još jedan slučaj gdje opseg može biti uzak. U rujnu 2025., Heroku je prijavio problem s uzvodnim DNS-om koji je odgodio pružanje DNS zapisa za nove aplikacije i domene. Službeni incident napomenuo je da novokreirana imena hostova mogu ostati nedostupna dok se problem s pružateljem usluga ne riješi, dok se opseg incidenta razvio kako bi uključio neke DNS pogreške za postojeće aplikacije iz regije EU.
Za praktičnu dijagnozu, testirajte postojeći Heroku naziv hosta odvojeno od nedavno dodane prilagođene domene. Također provjerite DNS razlučivost neovisno o ispravnosti aplikacije.
Samo kada smjernice za incident ili vaši vlastiti dokazi to podupiru. Ponovno pokretanje može pomoći kada je određeni dinamometar zaglavljen, ali također može ukloniti ispravan proces ili stvoriti dodatni odljev korisnika tijekom incidenta na cijeloj platformi.
Za incident od 10. lipnja 2025., Heroku je objavio specifično rješenje za aplikacije Private Space: pogođeni korisnici mogli su zaustavljati pojedinačne dinamometare jedan po jedan kako bi se zamijenili. Heroku je izričito upozorio da to ne jamči potpuni oporavak dok uzvodne usluge ostaju oštećene te da se dinamometar ne bi smjeli svi zamijeniti istovremeno. Te smjernice specifične za incident sačuvane su u službenom članku o sanaciji .
Nemojte generalizirati taj postupak na svaki prekid rada. Ako je baza podataka, sloj usmjeravanja, DNS davatelj ili Heroku Connect stvarno usko grlo, ponovno pokretanje web dynamometra možda neće ništa postići.
Nakon što se vrati dostupnost platforme, nizvodni sustavi još uvijek mogu nadoknaditi zaostatak. Heroku je rekao da su nakon prekida u lipnju 2025. isporučene e-poruke sa zakašnjenjem, sinkronizacija Heroku Connecta morala je nadoknaditi zaostatak, a faza izdavanja imala je zaostatak čije je rješavanje trajalo satima.
Za produkcijsku aplikaciju, validirajte oporavak kroz cijeli lanac ovisnosti:
Prekid rada Salesforce Herokua može utjecati na implementirane aplikacije na nekoliko različitih slojeva. Incidenti tijekom izvođenja i usmjeravanja mogu izravno učiniti aplikacije nedostupnima; incidenti s podacima mogu ostaviti procese u pogonu, ali prekinuti ključne značajke; incidenti s povezivanjem mogu uzrokovati zastarjelost podataka koje podržava Salesforce; a incidenti s alatima mogu blokirati implementacije bez utjecaja na izdanje koje je već u produkciji.
Najbolji operativni odgovor stoga nije "ponovno pokretanje svega". Prvo utvrdite je li kvar u Aplikacijama/Izvršavanju, Podacima, Alatima, DNS-u ili integraciji. Usporedite vlastite metrike sa Salesforce Trustom, sačuvajte dokaze, slijedite smjernice za ublažavanje specifičnih incidenata i provjerite svaku ovisnost nakon oporavka. Taj pristup smanjuje rizik pretvaranja incidenta platforme u vlastiti incident aplikacije.
Pregledajte značajne prekide rada Salesforcea u 2025. godini, što je zakazalo, koliko su dugo trajali odabrani incidenti i praktične lekcije o otpornosti koje timovi mogu primijeniti.
Izradite praktičan plan za kontinuitet zastoja u Salesforceu s analizom utjecaja, ciljevima RTO/RPO, ručnim rješenjima, kontrolama integracije i provjerama oporavka.
Naučite kako kontaktirati Salesforce podršku tijekom većeg prekida: provjerite status povjerenja, odaberite pravi kanal, otvorite snažan slučaj i pratite oporavak.
Rješavanje problema s prijavom u Salesforce Workbench, REST Explorerom, timeoutom, 503, verzijom API-ja i ograničavanje pogrešaka tijekom zastoja pomoću praktičnog dijagnostičkog popisa za provjeru.
Problemi sa StoreForceom mogu poremetiti raspoređivanje, evidenciju vremena i tijekove rada zaposlenika. Naučite kako procijeniti utjecaj, održati trgovine u funkciji, provjeriti oporavak i znati kada eskalirati problem.
Razumjeti glavne uzroke raširenih prekida rada u oblaku, kako se kvarovi kaskadno prenose, što prvo provjeriti i kako osmisliti otporniji plan oporavka.
If Datorama or Marketing Cloud Intelligence seems down, use this evidence-based checklist to verify the outage, protect reporting quality, and know when data is trustworthy again.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Understand how Salesforce and AWS connect through Hyperforce, integrations, networking, data residency, outages, and shared operational responsibilities.
Prekid rada AWS-a ne znači automatski da je Salesforce u kvaru. Saznajte kako Hyperforce, regije, instance i Salesforce Trust određuju je li vaša organizacija pogođena.
