The Prod3 & Prod1 environment is experiencing intermittent outages. We are currently investigating the issue.

We are currently investigating this issue.

The issue has been identified and a fix is being implemented.

A fix has been implemented and we are monitoring the results.

We are currently investigating this issue.

We are continuing to investigate this issue.

The issue has been identified and a fix is being implemented.

We are continuing to work on a fix for this issue.

A fix has been implemented and we are monitoring the results.

We are continuing to monitor for any further issues.

We are continuing to monitor for any further issues.

This incident has been resolved.

# Summary

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.

# Incident Details

## Incorrect Production Configuration Values Applied

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.

## Intermittent Login / Access Failures

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.

## Filestore Access Issue

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.

## Delayed Pipeline Execution Status Updates in UI

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.

# Impact Summary

• Service Manager and License Manager ran with incorrect configuration values in the Prod-1 and Prod-3 environments.
• Some users experienced intermittent login or access failures during the affected deployment window.
• One customer environment in Prod-3 experienced a filestore access issue.
• Users across affected environments saw delayed pipeline execution status updates in the UI; underlying pipeline executions continued to run correctly and were not lost, stuck, or corrupted.

# Preventive Actions

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._