Documented incidentIncident 2025-06-10Heroku (Salesforce)Engineering postmortem

Unplanned automatic OS update cuts networking for Heroku apps and its own status tools (2025)

An automated operating-system update ran on production hosts when it should have been disabled, and restarted their networking service.

What happened

  • A legacy script applied the correct routing rules only on first boot, so after the restart routes were not reapplied and dynos lost outbound connectivity; customers saw up to 24 hours of disruption.Summary of Heroku June 10 Outage
  • Heroku's internal tools and status page ran on the same affected infrastructure, which slowed its response and communication; Heroku disabled the automatic upgrades and committed to no changes outside its controlled deployment process.Summary of Heroku June 10 Outage

The failure pattern

Watch the pattern: Global change without a staged rollout

Safeguards that address it

CollectSEA's engineering analysis of what would have prevented or contained this failure.

  • Allow changes to production only through the controlled deployment pathDisable or block automatic package and OS upgrades on production hosts, so every change is staged and observable.
  • Keep incident tooling and status pages off the infrastructure they report onRun status pages and recovery tools on independent infrastructure so an outage cannot also silence the response.

Related standards

CollectSEA's mapping through this incident's failure pattern; not an official determination by the standards bodies.

Building something similar?

Describe your design and see every precedent that applies, with safeguards you can hand to your coding agent.

Analyze your design