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. Изпълнението на приложения може да се провали, дори когато кодът ви не е променен

Всички приложения на Heroku работят в управлявани контейнери, наречени dynos. Уеб dynos получават HTTP трафик, работните dynos обикновено обработват фонови задачи, а еднократните dynos се справят с административни задачи. Документацията за dyno на Heroku обяснява, че мениджърът на dyno е отговорен за поддържането на тези контейнери в експлоатация.

Следователно, проблем с платформата може да направи преди това здравословна версия недостъпна без внедряване на приложение. Ако хост мрежата, мениджърът на дино или основната инфраструктура станат недостъпни, приложението може да се провали, дори ако кодът и конфигурацията му са непроменени.

По време на прекъсването на 10 юни 2025 г., Heroku описа мрежова повреда, която прекъсна изходящата свързаност за динамометрите на засегнатите хостове. Това е важен оперативен урок: грешка, която изглежда като повреда на зависимостта на приложението, може да възникне под приложния слой.

2. Неуспехите при маршрутизиране могат да доведат до грешки 503, прекъсвания на времето или периодичен успех.

HTTP рутерите на Heroku получават входящ трафик и пренасочват заявки към уеб динамометри. Официалната документация за маршрутизиране описва този път от балансьорите на натоварването през рутерите до динамометрите на приложенията.

Ако само част от този път е нарушена, потребителите могат да съобщят, че сайтът „понякога работи“. Една заявка може да достигне до работещ динамометричен уред, докато друга се провали. Ето защо множество проверки от различни места са по-информативни от еднократно обновяване на браузъра.

Справката за кодове за грешки на Heroku е полезна, когато все още има налични лог файлове. H99 и R99 са специално документирани като грешки на платформата. Други кодове могат да показват изтичане на времето за изчакване на заявката, отказани връзки към backend, поставени под карантина динамометри или проблеми на ниво приложение, така че H-кодът сам по себе си не трябва автоматично да се обвинява за инцидент в целия Heroku.

3. Прекъсване на услугата за данни може да остави приложението работещо, но функционално неизползваемо

Едно приложение може да има работещи уеб динамометри, докато базата данни е бавна или недостъпна. Страниците, които не изискват данни, все още могат да се зареждат, докато влизането, плащането, търсенето, записът или API извикванията се провалят. Това създава частичен прекъсване, което може да изглежда непоследователно за крайните потребители.

Инцидентът от 8 май 2026 г. е полезен пример, тъй като Heroku съобщи за прекъсваща свързаност и повишена латентност на базата данни за засегнатите клиенти. Heroku също така посъветва засегнатите клиенти да обмислят превключване на базата данни при срив като смекчаваща мярка по време на инцидента.

Планираната поддръжка може да създаде и по-кратки прекъсвания. Документацията за поддръжка на Postgres на Heroku гласи, че поддръжката може да рестартира свързаното приложение и че потребителите могат да виждат грешки или забавяния в продължение на няколко минути. Следователно, планираната поддръжка и неочакван прекъсване на платформата трябва да се разграничат преди ескалиране на проблема.

4. Неуспехите в Heroku Connect могат да доведат до застаряване на данните от Salesforce, без да се налага да се спира уеб приложението.

Heroku Connect синхронизира данни между организация на Salesforce и Heroku Postgres. Според документацията на Heroku Connect , услугата осигурява синхронизация на данни, вместо да действа като самата уеб среда.

Ако Connect е прекъснат, внедреното приложение може да остане достъпно, докато синхронизираните данни на Salesforce спрат да се актуализират. Четенето от съществуващото копие на Postgres може все още да работи, но потребителите могат да виждат застояли записи или забавени записи в зависимост от съпоставянето и работния процес на приложението.

Документацията за поддръжка на Heroku посочва, че по време на поддръжката на Heroku Connect, синхронизацията и конфигурацията не са достъпни, докато съществуващите данни в Postgres остават достъпни; промените в опашката се запазват и синхронизацията се възобновява след това. Това поведение е документирано в „ Операции по поддръжка на Heroku Connect“ .

5. Проблемите с внедряването не означават непременно, че производството е спаднало

Операторите трябва да разделят „не може да се внедри“ от „приложението не е налично“. Heroku категоризира компилациите, Git push-овете, API-тата за внедряване, таблото за управление, CLI и свързаните с него операции за управление отделно от услугите за изпълнение и данни. Инцидент с инструментариума може да блокира ново издание, докато текущо изпълняваното издание продължава да обслужва трафик.

Тази разлика беше видима при инцидента на Heroku от 5 май 2026 г., когато някои клиенти не можаха да създават приложения за преглед, но Heroku изрично съобщи, че работещите приложения не са засегнати.

Документацията за фазата на издаване на Heroku също така отбелязва, че ако задача от фазата на издаване се провали, новата версия не се внедрява и текущата версия остава незасегната. По време на инцидент избягвайте да интерпретирате заседнал конвейер като доказателство, че активното приложение е претърпяло неуспех.

6. Инцидентите с DNS могат да засегнат новосъздадените приложения или домейни по различен начин от съществуващите.

DNS е друг случай, в който обхватът може да бъде стеснен. През септември 2025 г. Heroku съобщи за проблем с DNS нагоре по веригата, който забави предоставянето на DNS записи за нови приложения и домейни. Официалният инцидент отбеляза, че новосъздадените имена на хостове може да останат недостъпни, докато проблемът с доставчика не бъде разрешен, докато обхватът на инцидента се разви, за да включи някои DNS грешки за съществуващи приложения от региона на ЕС.

За практическа диагноза, тествайте съществуващото име на хост на Heroku отделно от наскоро добавения персонализиран домейн. Също така проверете DNS резолюцията независимо от състоянието на приложението.

Какво трябва да проверите първо по време на предполагаем прекъсване на Heroku?

• Първо проверете Salesforce Trust. Heroku казва, че Salesforce Trust се е превърнал в основен комуникационен канал за инциденти и поддръжка на 10 октомври 2025 г., като по-старият сайт на Heroku Status е запазен като паралелно резервно копие по време на прехода. Вижте документацията на Heroku Status .
• Определете засегнатата категория. Разделете приложенията/средата за изпълнение, услугите за данни и инструментите. Това предотвратява ненужни промени в приложенията по време на инцидент с платформата.
• Тествайте повече от началната страница. Проверете статична крайна точка, крайна точка, зависима от базата данни, фонови задачи и синхронизиран от Salesforce работен процес, ако е приложимо.
• Прегледайте кодовете за грешки и времевите отметки. Съпоставете грешките на рутера/runtime на Heroku с официалното време на започване на инцидента.
• Проверете дали внедряванията са просто блокирани. Ако производственият процес е в добро състояние, избягвайте налагането на внедряване по време на инцидент с нестабилна контролна равнина.
• Запазете доказателствата. Записвайте неуспешни заявки, лог файлове, показатели, латентност на базата данни, идентификатори на инциденти и точния UTC прозорец.

Трябва ли да рестартирате динометърите по време на прекъсване на електрозахранването?

Само когато указанията за инцидента или вашите собствени доказателства го подкрепят. Рестартирането може да помогне, когато даден динамометричен стенд е заседнал, но може също така да премахне здравословен процес или да създаде допълнителен отлив по време на инцидент на цялата платформа.

За инцидента от 10 юни 2025 г. Heroku публикува специфично решение за приложенията Private Space: засегнатите клиенти можеха да спират отделни динометъри един по един, така че те да бъдат подменени. Heroku изрично предупреди, че това не гарантира пълно възстановяване, докато услугите нагоре по веригата остават нарушени, и че динометърите не трябва да бъдат подменяни едновременно. Това специфично за инцидента ръководство е запазено в официалната статия за отстраняване на проблеми .

Не обобщавайте тази процедура за всеки прекъсване. Ако базата данни, рутиращото ниво, DNS доставчикът или Heroku Connect са действителното пречка, рестартирането на уеб динамометрите може да не постигне нищо.

Възстановяването не е завършено, когато началната страница се появи отново за първи път.

След като наличността на платформата се възстанови, системите надолу по веригата все още могат да наваксат. Heroku заяви, че след прекъсването през юни 2025 г. са били доставяни забавени имейли за състоянието, синхронизацията на Heroku Connect е трябвало да навакса, а фазата на пускане на пазара е имала натрупани задачи, чието изчистване е отнемало часове.

За производствено приложение, валидирайте възстановяването по цялата верига на зависимости:

• Процентът на успеваемост и латентността на HTTP са се нормализирали.
• Всички очаквани уеб и работни динамометри са в изправност.
• Четенето и записването в базата данни се осъществяват успешно с нормална латентност.
• Опашките и планираните задачи се обработват, вместо да се натрупват.
• Съпоставянията на Heroku Connect се синхронизират, ако се използват.
• Разгръщанията и заданията във фазата на пускане на пазара работят нормално.
• Логовете и показателите пристигат без необичайно забавяне.
• Добавките на трети страни и външните API са възстановени.

Долен ред

Прекъсване на Salesforce Heroku може да повлияе на внедрените приложения на няколко различни слоя. Инцидентите по време на изпълнение и маршрутизация могат директно да направят приложенията недостъпни; инцидентите с данни могат да оставят процесите работещи, но да прекъснат основните функции; инцидентите с свързване могат да направят данните, поддържани от Salesforce, остарели; а инцидентите с инструменти могат да блокират внедряванията, без да засегнат вече съществуващата продукция.

Следователно най-добрият оперативен отговор не е „рестартиране на всичко“. Първо определете дали повредата е в Приложения/Среда за изпълнение, Данни, Инструменти, DNS или интеграция. Сравнете собствените си показатели със Salesforce Trust, запазете доказателства, следвайте специфичните за инцидента указания за смекчаване на последиците и проверете всяка зависимост след възстановяване. Този подход намалява риска от превръщане на инцидент на платформата в инцидент на приложението.