Astronomer Outage History

We have identified a recent change that broke the templating of the deploymentId and workspaceId fields used in the Astro Alert emails for Dag Success and Failure emails. We are working on a fix and will provide updates shortly.

Correction: Deployment and Workspace _names_ are not populated, earlier update cited IDs incorrectly.

We have identified a regression affecting custom roles due to a change rolled out today. This resulted in permissions being dropped from custom roles silently. We have received reports of deploys linked to tokens using custom roles not working. Until the fix has been rolled out, deploy failures can be mitigated by re-adding the `deployment.deploys.create` permission to your custom role. You may also manually restore any other permissions that were silently dropped. We are working on fixing this regression for all affected custom roles.

We have identified the cause. On Astro, each worker queue is backed by a Kubernetes autoscaling resource whose name is built from a fixed platform prefix, the deployment release name, and the worker queue name. For a very small number of customers, where that combined name exceeds the Kubernetes 63-character limit, the autoscaling resource is rejected at creation. As a result, workers do not scale for the affected queue and tasks routed there remain in the queued state. This is why the limit can be reached even when the worker queue name itself looks short: the release name and platform prefix already consume a large portion of the 63 characters before the queue name is appended. Workaround: If affected, until the permanent fix is deployed, please keep worker queue name at or below 10 characters. We are preparing a permanent fix. Further updates to follow.

The potential root cause identified, and fix is underway

We've identified the cause of the false availability alerts that have been showing the Astro UI. This is a degradation affecting dashboard and monitoring visibility only. Task execution, scheduling, and workflow processing have not been impacted. The issue is the result of a metrics reporting bug that has been intermittently flagging scheduler heartbeats as missed when they were not. We are actively rolling out a fix that corrects how these metrics are reported.

We've identified a change that enabled GPU support for KubernetesPodOperator pods had an unintended side effect when reading pod specs without proper limits set in the expected format. We're working on a fix, if you notice any unexpected failures for KPO tasks in your Astro deployments, please open a support ticket.

We have identified the source of increased log generation volume, which is causing issues on the ingestion side. We're implementing mitigations now and are monitoring the results.

We are continuing to investigate and monitor this issue.

**The issue, according to Azure status page** Investigating a spike in 401 authentication errors We are actively investigating customer alerts of 401 authentication errors when pulling images from mcr.microsoft.com. We've identified a potential underlying factor related to a recent update made to a backed service and we are actively working on determining mitigation workstreams. More information will be provided shortly. This message was last updated at 23:04 UTC on 15 June 2026

We've identified an issue with `astro deploy`s not updating manifests in Astro Hosted clusters, and we're currently applying a workaround and are continuing to monitor the situation.

We have identified the cause of the delayed delivery for some time-based alerts and are implementing a fix. We will provide another update once the fix has been deployed and validated.

A fix has been prepared and is moving through deployment. We will provide another update once the rollout is complete and validation is underway.

Azure East US has reported multi-service impact that is affecting Astro deployments in the region. For more information on Azure outage, please visit: https://azure.status.microsoft/en-us/status

We have identified the issue and we are rolling out the fix for the affected deployments.

We have identified that Runtime 3.2-1 is incompatible with the Astro Environment Manager. Any Connections or Variables stored at the Workspace level will not be available on deployments running 3.2-1. For this reason, we have disallowed the use of 3.2-1 for any deployments which are not already on that version. We are working to release a 3.2-2 version that is properly compatible as quickly as possible.

We are currently investigating an issue affecting deployments in our Azure West Europe region. Some customer deployments are experiencing degraded performance due to a compute resource constraint in our shared infrastructure. Our engineering team has identified that the region has reached its vCPU quota limit for a specific compute type, which is preventing new resources from being provisioned. We have opened a high-priority support request with Azure to increase this quota and are actively working with our Azure representative to expedite the approval. We will provide updates as soon as we have more information about the timeline for resolution. We apologize for any disruption this may cause to your service.

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