Technology1 min read

Incident Report: August 11, 2026

By · Published by Everything Blog

In short

The incident began between 3:09 PM and 3:27 PM EDT when an update to team ownership metadata stripped cache permissions from newly scaled service instances. When engineers executed a global rollback to address localized latency, all instances restarted without cache access, forcing them to query the database directly and causing widespread connection pool exhaustion. Engineers fully restored operations by reverting the metadata changes and restarting the instances to re-enable caching. HubSpot is now decoupling permissions from team ownership and requiring authorization updates to follow staged rollout procedures.

Key points

  • Global users faced consistent failures when attempting to load core CRM record pages, tho…: Global users faced consistent failures when attempting to load core CRM record pages, though no customer data was lost.
  • Critical services will transition from team-based permissions to service-based permission…: Critical services will transition from team-based permissions to service-based permissions to prevent similar configuration failures.
  • Future authorization configuration updates will undergo the same staged rollout procedure…: Future authorization configuration updates will undergo the same staged rollout procedures typically reserved for standard code deployments.

Sources checked by our analysis pipeline: 1

On August 11, 2026, between 3:09 PM and 3:27 PM EDT (UTC-4), HubSpot customers experienced an outage of the CRM Record Page. During this time, a large portion of CRM record page loads failed. No data was lost during this incident, and services outside of the CRM record page were unaffected. We have completed a thorough analysis of this incident, and below is a detailed account of what happened, why it occurred, and the steps we are taking to prevent similar issues in the future.

What Happened

On Tuesday, August 11th, our engineering team modified metadata on a core CRM backend service, updating team ownership to reflect organizational changes. This update caused any newly launched service instance to lack access to a distributed cache. When two new instances launched in response to scaling signals, they failed cache record lookups and queried the underlying database instead. This created pressure on the database’s resources and caused minor elevated latency and timeouts for the requests they served.

Our reliability automation alerted the engineering team of traffic degradation due to the two instances that…

Technology