Astronomer had 48 outages in the last 2 years totaling 265h 6m of downtime — averaging 2 incidents per month.
There were 48 Astronomer outages since March 26, 2025 totaling 265h 6m of downtime. Each is summarised below — incident details, duration, and resolution information.
https://www.astronomer.io/docs/astro/deployment-health-incidents
Deployment Health Incidents have been temporarily disabled.
We are currently investigating this issue.
Deployment Health Incidents may not be working https://www.astronomer.io/docs/astro/deployment-health-incidents
Deployment Health Incidents may not be working https://www.astronomer.io/docs/astro/deployment-health-incidents
This incident has been resolved.
We are currently investigating an apparent issue with Azure's Front Door CDN that is causing DNS timeouts and unavailability of the Astro Cloud UI. Airflow deployments are unaffected and continue to process tasks. We have updated our DNS routing to bypass Front Door for now and are seeing access to the Cloud UI being restored.
A fix has been implemented and we are monitoring the results.
We are continuing to monitor for any further affects from this Azure outage. You can follow Azure's status here: https://azure.status.microsoft/en-us/status
Resolved per Azure status; https://azure.status.microsoft/en-us/status
We are currently investigating this issue and have been notified by AWS of issues with VM scale ups in AWS us-east-1, specifically the use1-az2 AZ. We are working to identify affected deployments, as well as on mitigations.
Customer deployments should no longer be affected, we are monitoring to confirm resolution.
This incident has been resolved.
We are aware of an ongoing AWS outage in the US-EAST-1 (N. Virginia) region that is impacting multiple AWS services and related infrastructure components. Customers with Astro clusters and deployments hosted on AWS may experience degraded performance, failed task executions, or delays in accessing their environments. Our team is actively monitoring the situation and assessing the impact across affected deployments. For real-time updates from AWS, please refer to their Service Health Dashboard - https://health.aws.amazon.com/health/status Next update will be provided as more information becomes available.
We are continuing to investigate this issue.
We’re aware that the Airflow UI has been running very slowly following the recent AWS outage. Our team is actively investigating the issue.
The AWS outage is affecting an internal tool, which is causing Airflow UI slowness in clusters running on all clouds (not just AWS). Our development team is working on a fix.
We are continuing to investigate this issue.
We have made a hotfix update to Astro to relieve the Airflow UI slowness in Azure, GCP, and in AWS regions other than us-east-1. We are continuing to monitor the impact of the change, but early signs indicate that the speed of the UI should be improving. This update has no effect on the issues unique to deployments in AWS us-east-1.
We have observed pods that were previously stuck in the pending state slowly getting scheduled on EC2 nodes following mitigations applied by the AWS team. This should start resolving issues with task execution. We are actively monitoring the situation.
All Astronomer components have returned to a healthy state.
We are investigating this issue and have identified the source of the issue and are putting mitigations in place. Airflow deployment task execution is unaffected. Dag triggering via Airflow API may experience intermittent issues.
The root cause of this incident has been fully identified, and our engineering teams are continuing to work on implementing mitigations. We are also continuing to monitor this issue and the underlying systems associated. Incidence of this issue has dropped significantly, however degraded performance is still possible.
This incident has been resolved.
We are currently investigating some hosted clusters experiencing an unintentional reduction in ephemeral storage for default kubernetes pods
The issue has been identified and a fix is being implemented.
This incident has been resolved.
We are currently migrating our docs to a new platform. All docs are working except the docs for our self-hosted platform generally referred to as Astronomer Software. You can find a working mirror here https://clear-mousepad.cloudvent.net/docs/software/
The issue has been identified and a fix is being implemented.
This incident has been resolved.
We are aware of an issue affecting live task logs with Runtime 3.0-7 and are actively investigating the issue
The issue has been identified and a fix is being implemented.
Astro Runtime 3.0-8 has been released, which contains the fix for this issue. Release notes are available here: https://www.astronomer.io/docs/astro/runtime-release-notes#astro-runtime-30-8
We are seeing reports that users of Astro Observe are getting false positive alerts for Data Freshness SLAs. We are currently investigating the cause of these false positives.
A fix has been implemented for the false positive alerts affecting Data Freshness SLAs in Astro Observe. Improvement has been observed, we'll continue monitoring to ensure full resolution.
The false positive alerts for Data Freshness SLAs in Astro Observe have been resolved.
We are actively investigating the issue.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
A fix has been implemented and we are monitoring the results.
This incident has been resolved.
Google Cloud has put up a status page indicating that several services in us-east1 are affected by an incident. Astro clusters in this region will be affected by this. Clusters in other regions and other clouds should not be affected, as none of the control plane components for Astro are hosted in this region. For more information, follow the GCP incident: https://status.cloud.google.com/incidents/8cY8jdUpEGGbsSMSQk7J
Per Google, this outage is now resolved.
We’re currently investigating an issue where GitHub Integration image deploys are failing.
The issue affecting GitHub Integration image deploys has been resolved.
Some clusters that were updated today will fail to run any KPO tasks
The issue has been identified and a fix is being implemented.
A fix has been implemented. We are currently monitoring the results.
This incident has been resolved.
Upgrading to Astro CLI version 1.35 can lead to unintended changes in your worker queues settings, particularly when deploying with modified or missing workerQueues definitions. Please use CLI version 1.34 or lower.
We’ve identified the root cause of the issue in Astro CLI version 1.35 that results in unintentional modifications to worker queues. We have yanked Astro CLI 1.35. Yanked release: https://github.com/astronomer/astro-cli/releases/tag/v1.35.0
Deploys using Astro CLI version 1.35 are now blocked to prevent unintentional changes to worker queues. Please use CLI version 1.34 or lower.
We’ve verified that all affected customers have been contacted regarding the issue with Astro CLI version 1.35.0.
There is an active GCP outage that is affecting Astro customers using GCP
https://status.cloud.google.com/ We will continue to monitor the issue and update this page
At this time we believe that Deployments on Azure and AWS are unaffected. We are currently checking our components to be certain. We have seen task failure rates increase on Astro Deployments on GCP. We will pass along any updates we receive from Google regarding this issue.
Updates from status.cloud.google.com indicate most if not all of the issues are no longer occurring. On Astro, we have seen our metrics return to normal. We tentatively believe that this problems affecting Astro have passed. We continue to monitor the situation.
This incident appears to be resolved as it pertains to Astro.
If you create certain Connection types in the Environments menu, it can crash your browser tab. Currently it affects SSH, SMTP, SFTP, Postgres, and Generic. There could be others. We are investigating currently.
The issue has been identified, and our team is actively working on a fix.
This issue has been resolved.
A small subset of customers have reported 403 errors when running the astro deploy command to deploy a new image. We are actively investigating this issue. If you are experiencing these errors, we encourage you to contact support and include the login command you used, astro cli and docker versions, and any log messages.
We've implemented a mitigation for this issue and the affected clusters should see successful image pushes. We will continue to monitor for additional errors.
We have determined that this error is caused by cached credentials which are no longer valid after an internal change in Astro to the image registry. The fix must be performed client-side (i.e. on the machine running `astro deploy`). If you experience this error, run `docker logout` for each Astro registry that this machine has cached credentials for. By default, credentials are stored in ~/.docker/config.json, and if you are using this default setting, the following bash script will identify cached credentials and run docker logout for those that correspond to Astro registries. for domain in $(grep 'registry.astronomer.run' ~/.docker/config.json | awk '{print $1}' | tr -d '":' | sort | uniq); do docker logout "$domain" done
We are currently investigating the issue.
Fix has been validated and is rolling out to affected deployments.
This incident has been resolved.
In some deployments, worker pods are getting stuck in the initialization state for an extended period of time. Due to this, queued tasks are unable to run and fail. This is not affecting all deployments. We are investigating which deployments are affected and why.
We are continuing to investigate this issue.
The incident is resolved.
This incident has been resolved.
Data shown in the Organization Dashboards Cost Breakdown (for Enterprise customers) is delayed. As stated on the page itself, the latest data is as of April 4th. The processing to update this dashboard is currently ongoing, and we expect the data to be refreshed at approximately 16:00 UTC.
Deployment cost is now up to date, but compute costs for some customers remain outdated. We were working with our billing vendor to determine the source of the issue.
This issue is now resolved except for one customer who we have contacted directly.