During a recent production deployment, a defect in our internal deployment tooling caused two critical services to run with incorrect, non-production configuration values in our production environment This led to a related set of four distinct symptoms: incorrect configuration behavior, intermittent login/access failures, a filestore access issue affecting one customer environment, and delayed pipeline status updates in the UI.
We have identified and are implementing a permanent fix for the underlying configuration defect, and have already put in place resource and capacity changes that resolve the UI delay symptom.
At no point during this incident were pipeline executions themselves lost, corrupted, or left in a stuck state. Where execution behavior was affected, it was limited to delays in status visibility, not in the underlying processing.
Our engineering team confirmed a defect in the Service Manager deployment pipeline that caused certain production services to be deployed using configuration values intended for a different environment, rather than the correct production configuration.
Root Cause
The service responsible for fetching configuration overrides during deployment queries an internal API that returns a maximum of 1,000 results per request. The total number of services in the environment recently grew beyond that limit. As a result, any service beyond the first 1,000 returned was not included in the response, and the deployment pipeline silently fell back to default configuration values for those services. This is a confirmed pagination defect in the deployment tooling, not an issue with the configuration values themselves.
Resolution
Engineering has confirmed the mechanism and is implementing a permanent fix to remove this limit-related gap in the deployment pipeline.
During the Service Manager deployment referenced above, some users experienced intermittent login or access failures. Under normal operation, previously running instances should continue serving traffic without interruption while a new deployment is in progress. In this incident, that fallback behavior did not occur as expected, contributing to access failures during the deployment window.
A filestore access issue was identified that was specific to the Prod-3 environment and affected a single customer's environment.
Root Cause
This is related to an IAM / storage-bucket permission configuration on Service Manager, potentially triggered by rollback activity.
Some users observed that the pipeline execution graph in the UI was slow to refresh and did not reflect the latest status promptly. Importantly, this was a visibility delay only: there was no impact to actual pipeline executions, and no executions were stuck or failed as a result of this issue.
Root Cause
The pipeline execution graph relies on a message stream (the orchestration log) to receive status updates. During the incident window, consumer processing of this stream fell behind (high consumer lag), which delayed how quickly status updates reached the UI. This was caused by the fact that the underlying database was in the middle of a planned scaling operation at the same time, and a traffic spike during that window further exacerbated the delay. Users experienced this as apparent pipeline slowness, even though the underlying executions were running normally.
Resolution
We have increased resource capacity for the affected components to maintain more than 50% spare headroom going forward, reducing sensitivity to similar load spikes. This change has been implemented and is currently being validated as part of longer-term hardening for this part of the platform.
The following corrective and preventive actions have been identified.
Corrective / Preventive Action Correct the pagination limit in the configuration-lookup service so that all services are returned and evaluated, regardless of total count. Add safeguards so that a service which cannot retrieve its configuration fails safely (e.g. alerts and blocks the deployment) rather than silently falling back to non-production defaults. Increase Postgres and messaging-pipeline resource headroom (target: greater than 50% spare capacity) to reduce sensitivity to concurrent load and scaling events.
We recognize the impact this incident had across multiple areas of the platform and appreciate your patience as we work through a complete resolution.