Astronomer Outage History

Started Oct 22, 2026, 12:01 AM UTC· resolved Oct 23, 2026, 09:28 PM UTC

1. identified Oct 22, 2026, 12:01 AM UTC

   Astronomer has released Runtime updates to address a publicly disclosed security vulnerability concerning private keys associated with eight eMudhra/emSign intermediate certificate authority (CA) certificates. For additional background, visit https://emudhra.we-have-a-problem.com/. Scope and available updates This advisory stems from an issue with a third-party certificate authority. Action required for customer-managed components depends on their specific certificate trust stores and verification mechanisms. The following Runtime releases incorporate certificate trust updates to mitigate this vulnerability: • Runtime 13: 13.12.1 • Runtime 3.0: 3.0-20 • Runtime 3.1: 3.1-23 • Runtime 3.2: 3.2-12 • Runtime 3.3: 3.3-10 For full details, please refer to the Runtime release feed: https://www.astronomer.io/docs/runtime/runtime-release-feed. Recommended customer actions • Upgrade to the appropriate updated Runtime release for your environment. • Rebuild and redeploy custom images using the updated base image. Refer to our mitigation guide: https://www.astronomer.io/docs/runtime/mitigate-emudhra-ca-compromise for step-by-step instructions. • Audit customer-managed build pipelines and tooling, applying relevant vendor updates to certificate trust stores and signature verification components. • Ensure TLS and code-signature verification remain enabled. If updates cause validation failures, contact the endpoint owner or software publisher for replacement certificate or artifact guidance. Please note that Runtime updates address the trust components included within those specific releases. Customer-added dependencies, custom certificate bundles, and external tooling may require separate updates. Support and further guidance If you are unable to upgrade or require assistance determining the applicable next steps, please contact [email protected]: mailto:[email protected]. Include your deployment model, Runtime version, and whether you maintain custom images or build pipelines. Additional mitigation guidance is currently being finalized. We will update this advisory as further details and Remote Execution releases are confirmed.

2. resolved Oct 23, 2026, 09:28 PM UTC

   We have now released updated agent client patches for use in Remote Execution deployments that incorporate certificate trust updates to mitigate the vulnerability. These are 1.8.11, 1.7.7, and 1.6.5. See more details in the Agent Release Notes: https://www.astronomer.io/docs/runtime/runtime-release-feed. Additionally, we have released another update of the Runtime images to handle the following two changes related to this vulnerability. • New virtual environments created with python -m venv now get pip 26.2.2 • Upgrade grpcio to 1.84.1, whose bundled CA list no longer includes the roots affected by the eMudhra compromise The following Runtime image versions include these changes. For more details see Runtime Release Notes: https://www.astronomer.io/docs/runtime/runtime-release-feed. • Runtime 13: 13.12.2 • Runtime 3.0: 3.0-21 • Runtime 3.1: 3.1-24 • Runtime 3.2: 3.2-13 • Runtime 3.3: 3.3-11

Read the full incident report →

Started Oct 20, 2026, 06:40 AM UTC· resolved Oct 21, 2026, 08:49 AM UTC

1. investigating Oct 20, 2026, 06:40 AM UTC

   We are investigating an issue where Astro Alerts notifications may be delayed for some customers. Our team is actively working to resolve the issue, and we will provide an update as soon as we have more information.

2. identified Oct 20, 2026, 07:55 AM UTC

   We have identified the cause and are rolling out a fix to the affected deployments. Alerts held during the incident have started to be delivered, and some alerts may continue to be delayed until the rollout is complete. We will provide another update once the fix is fully rolled out.

3. identified Oct 20, 2026, 10:42 AM UTC

   The fix has been applied to the majority of affected deployments, and delayed alerts continue to be delivered as we process the backlog. We are addressing a small number of remaining deployments and will provide another update once this is complete.

4. monitoring Oct 20, 2026, 12:38 PM UTC

   The backlog of delayed Astro Alerts has been fully processed, and we are monitoring recovery following the fix. A small number of alerts may still be briefly delayed as the fix completes on remaining systems.

5. resolved Oct 21, 2026, 08:49 AM UTC

   Astro Alerts delivery has returned to normal, and this incident is resolved. We have applied the fix and fully processed the backlog of delayed alerts. Thank you for your patience while we worked to restore service.

Read the full incident report →

Started Oct 19, 2026, 09:37 AM UTC· resolved Oct 19, 2026, 11:00 AM UTC

1. investigating Oct 19, 2026, 09:37 AM UTC

   We are currently investigating this issue. We will keep this page updated as we have more information.

2. identified Oct 19, 2026, 10:28 AM UTC

   We have identified the source of the issue and are actively working on a fix. We’ll share further updates as we make progress.

3. resolved Oct 19, 2026, 11:00 AM UTC

   The issue has been resolved, and the Organization Dashboards are now working as expected.

Read the full incident report →

Started Oct 13, 2026, 06:02 PM UTC· resolved Oct 13, 2026, 06:28 PM UTC

1. investigating Oct 13, 2026, 06:02 PM UTC

   The Astro Core API is showing an elevated number of errors. We are investigating actively and will update as soon as we know more. Next update will be within the next 30 minutes.

2. investigating Oct 13, 2026, 06:13 PM UTC

   Our metrics indicate no impact on existing tasks and Dag Runs. They are continuing to run successfully. We are continuing to investigate what is causing the API and UI errors and are attempting a workaround.

3. monitoring Oct 13, 2026, 06:28 PM UTC

   We have restarted one of our services that was experiencing higher than expected load. This has returned the Astro UI and API to functionality. We are continuing to investigate root cause.

4. resolved Oct 13, 2026, 07:53 PM UTC

   We have identified the proximate cause of the incident and are confident that the situation is stable. We will follow up with more detail in a postmortem at a later date.

Read the full incident report →

Started Oct 06, 2026, 03:33 AM UTC· resolved Oct 14, 2026, 12:34 AM UTC

1. investigating Oct 06, 2026, 03:33 AM UTC

   We are currently seeing a capacity shortage in the Google Cloud (GCP) us-central1 region. As a result, some Deployments running in this region may experience delays when scaling up worker nodes and pods. Some tasks may remain in a queued state for longer than usual while waiting for compute capacity. In some cases, tasks that stay queued beyond their configured timeout may fail. Recommended workaround: Configuring automated task retries (for example, setting retries and a retry_delay on your tasks or in your DAG's default_args) will help tasks recover automatically once capacity becomes available. https://www.astronomer.io/docs/learn/rerunning-dags#automatically-retry-tasks We are working to address the issue and keep this page posted as we have more updates.

2. resolved Oct 14, 2026, 12:34 AM UTC

   We have seen improved capacity in the GCP us-central1 region across additional machine types, and error rates for worker node and pod scale-up have dropped. If any tasks failed during this incident, you can clear and rerun them. To recover automatically from future capacity constraints, we recommend setting retries and retry_delay on your tasks or in default_args. If you’re still seeing issues, please contact Astronomer Support.

Read the full incident report →

Started Oct 03, 2026, 08:42 PM UTC· resolved Oct 03, 2026, 09:39 PM UTC

1. identified Oct 03, 2026, 08:42 PM UTC

   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.

2. identified Oct 03, 2026, 09:03 PM UTC

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

3. monitoring Oct 03, 2026, 09:13 PM UTC

   We have reverted the problematic email template changes and are continuing to monitor for full resolution.

4. resolved Oct 03, 2026, 09:39 PM UTC

   All Astro Alert emails for Dag Success/Failure now correctly include the deployment/workspace name.

Read the full incident report →

Started Oct 01, 2026, 10:40 PM UTC· resolved Oct 01, 2026, 11:47 PM UTC

1. investigating Oct 01, 2026, 10:40 PM UTC

   We have identified several hosted deployments where tasks are getting stuck in the queued state and failing. This is happening the worker autoscaler is having issues with scaling up workers to run tasks. We are investigating the cause of this.

2. resolved Oct 01, 2026, 11:47 PM UTC

   Our development team has concluded that this was a false alert. It is not affecting multiple deployments.

Read the full incident report →

Started Sep 24, 2026, 02:52 PM UTC· resolved Sep 24, 2026, 03:34 PM UTC

1. investigating Sep 24, 2026, 02:52 PM UTC

   We are investigation reports that the Deployments view of the Astro Cloud UI is unavailable. We will update as we know more.

2. investigating Sep 24, 2026, 02:56 PM UTC

   We have confirmed that task execution is unaffected. We're continuing to investigate.

3. monitoring Sep 24, 2026, 03:19 PM UTC

   We have rolled back an identified breaking change, and are beginning to see error rates decrease. Please refresh the Astro Cloud UI in your browser.

4. resolved Sep 24, 2026, 03:34 PM UTC

   Issue has been resolved and error rates have returned to baseline. If you are still experiencing issues please refresh the page, and open a support ticket if that does not resolve the issue.

Read the full incident report →

Started Sep 17, 2026, 05:54 PM UTC· resolved Sep 17, 2026, 07:29 PM UTC

1. identified Sep 17, 2026, 05:54 PM UTC

   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.

2. monitoring Sep 17, 2026, 07:29 PM UTC

   All custom roles have been restored to their previous functionality and full operation has been restored.

3. resolved Sep 17, 2026, 09:50 PM UTC

   No further issues have been found, so this is being marked as resolved.

Read the full incident report →

Started Sep 08, 2026, 12:33 PM UTC· resolved Sep 08, 2026, 08:09 PM UTC

1. identified Sep 08, 2026, 12:33 PM UTC

   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.

2. monitoring Sep 08, 2026, 07:42 PM UTC

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

3. resolved Sep 08, 2026, 08:09 PM UTC

   The incident has been resolved.

Read the full incident report →

Started Sep 04, 2026, 03:08 AM UTC· resolved Sep 04, 2026, 06:07 AM UTC

1. investigating Sep 04, 2026, 03:08 AM UTC

   We are currently investigating an issue affecting deployment access, authentication, and related services for multiple customers. Some users may experience 401 errors when using organization-based Astronomer URLs (ORG_ID.astronomer.run), as well as "RBAC: access denied" errors or difficulty viewing DAGs in the Astronomer UI.

2. investigating Sep 04, 2026, 04:28 AM UTC

   We're continuing to investigate the issue affecting access/auth to some deployments and services. We will follow up with an update no later than 5:30 AM UTC on Friday, September 4, 2026, or sooner if we have something to share.

3. identified Sep 04, 2026, 04:52 AM UTC

   The potential root cause identified, and fix is underway

4. monitoring Sep 04, 2026, 05:53 AM UTC

   We identified and resolved an infrastructure configuration issue that was causing authentication failures and deployment access errors across the platform. The root cause was a network configuration change during an infrastructure upgrade that temporarily disrupted connectivity between our control plane and customer deployments. The fix has been applied and initial validation confirms services are recovering We are actively monitoring to confirm full recovery across all affected deployments. If you are still experiencing issues, please contact support.

5. resolved Sep 04, 2026, 06:07 AM UTC

   The issue has been fully resolved. All services, including authentication, deployment access, and DAG visibility, are operating normally. We apologize for the disruption and thank you for your patience.

Read the full incident report →

Started Sep 01, 2026, 06:40 PM UTC· resolved Sep 01, 2026, 10:29 PM UTC

1. investigating Sep 01, 2026, 06:40 PM UTC

   We are currently investigating a Google Cloud networking incident that may affect Astro deployments running in the us-central1 region. Customers may see intermittent networking connectivity disruptions, DNS resolution errors, or missing metrics from Airflow deployments. For more information, see the Google Cloud status incident "Google Cloud status incident": https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev.

2. investigating Sep 01, 2026, 06:43 PM UTC

   We are currently investigating a Google Cloud networking incident that began around 16:03 UTC and may affect Astro deployments running in the us-central1 region. Customers may see intermittent networking connectivity disruptions, DNS resolution errors, or missing metrics from Airflow deployments. For more information, see the Google Cloud status incident "Google Cloud status incident": https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev.

3. investigating Sep 01, 2026, 06:44 PM UTC

   We are currently investigating a Google Cloud networking incident that began around 16:03 UTC and may affect Astro deployments running in the us-central1 region. Customers may see intermittent networking connectivity disruptions, DNS resolution errors, or missing metrics from Airflow deployments. For more information, see the Google Cloud status incident "Google Cloud status incident": https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev.

4. investigating Sep 01, 2026, 07:05 PM UTC

   We are investigating a Google Cloud networking incident that began around 14:41 UTC and may affect Astro deployments running in the us-central1 region. Customers may see intermittent networking connectivity disruptions, DNS resolution errors, or missing metrics from Airflow deployments. For more information, see the Google Cloud status incident "Google Cloud status incident": https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev.

5. monitoring Sep 01, 2026, 07:19 PM UTC

   Google Cloud has resolved the networking incident affecting us-central1. The incident ran from approximately 14:44 UTC to 18:52 UTC. During this period, some Astro deployments in us-central1 may have experienced intermittent networking connectivity disruptions, DNS resolution errors, or missing metrics from Airflow deployments.

6. monitoring Sep 01, 2026, 08:42 PM UTC

   Google Cloud has resolved the networking incident affecting us-central1. The incident ran from approximately 14:44 UTC to 18:52 UTC. During this period, some Astro deployments in us-central1 may have experienced intermittent networking connectivity disruptions, DNS resolution errors, or missing metrics from Airflow deployments. This issue has since been resolved by Google, but we are continuing to monitor the situation internally to ensure it's resolution.

7. resolved Sep 01, 2026, 10:29 PM UTC

   The GCP incident is marked as Closed officially

Read the full incident report →

Started Aug 18, 2026, 06:51 PM UTC· resolved Sep 10, 2026, 10:19 PM UTC

1. investigating Aug 18, 2026, 06:51 PM UTC

   Our metrics pipeline is falsely displaying spikes in scheduler heartbeat metrics, despite underlying component health.

2. identified Sep 08, 2026, 06:31 PM UTC

   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.

3. resolved Sep 10, 2026, 10:19 PM UTC

   This issue is now resolved.

Read the full incident report →

Started Aug 18, 2026, 04:17 AM UTC· resolved Aug 18, 2026, 07:36 AM UTC

1. investigating Aug 18, 2026, 04:17 AM UTC

   We have identified an issue affecting an internal rollout related to the pre_execute Airflow hook in Astro Hosted. We have identified a fix and are rolling it out across the fleet. We are monitoring the rollout and will provide further updates as it progresses.

2. monitoring Aug 18, 2026, 04:18 AM UTC

   Fix is being rolled out across all astro deployments.

3. resolved Aug 18, 2026, 07:36 AM UTC

   Rollout has been completed

Read the full incident report →

Started Aug 04, 2026, 03:11 PM UTC· resolved Aug 04, 2026, 04:40 PM UTC

1. identified Aug 04, 2026, 03:11 PM UTC

   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.

2. monitoring Aug 04, 2026, 03:15 PM UTC

   We have rolled back the changes that triggered this issue and are monitoring the issue for confirmation that this issue is resolved.

3. resolved Aug 04, 2026, 04:40 PM UTC

   Mitigations have been successful. A Platform release that corrects this errant behavior is being worked on now. Issue is resolved.

Read the full incident report →

Started Aug 04, 2026, 12:57 PM UTC· resolved Aug 04, 2026, 01:34 PM UTC

1. investigating Aug 04, 2026, 12:57 PM UTC

   We are investigating intermittent connectivity issues affecting clusters in Azure Central US when calling Astronomer APIs. This may prevent or delay attempts to create, update, or delete Airflow Deployments. Our engineering team is actively investigating the issue and working to restore normal service.

2. monitoring Aug 04, 2026, 01:34 PM UTC

   Affected clusters have recovered and are operating normally. We are continuing to monitor the environment to ensure service stability.

3. resolved Aug 04, 2026, 02:36 PM UTC

   This interruption has been resolved.

Read the full incident report →

Started Jul 30, 2026, 04:02 PM UTC· resolved Jul 30, 2026, 10:38 PM UTC

1. investigating Jul 30, 2026, 04:02 PM UTC

   We are currently investigating an issue with platform log ingestion for Astro. Logs may not be available in the Cloud UI.

2. investigating Jul 30, 2026, 04:33 PM UTC

   We are continuing to investigate this issue, and will provide another update in 30mins or as new information is available.

3. identified Jul 30, 2026, 06:03 PM UTC

   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.

4. identified Jul 30, 2026, 06:43 PM UTC

   We are continuing to investigate and monitor this issue.

5. monitoring Jul 30, 2026, 07:06 PM UTC

   We are beginning to see ingestion catch up with backlog log load. Customers may begin to see some logs becoming available in the Cloud UI

6. monitoring Jul 30, 2026, 08:05 PM UTC

   We continue to see log ingestion improving on the platform, and we're continuing to monitor the situation.

7. monitoring Jul 30, 2026, 09:47 PM UTC

   We are continuing to see progress as the log injestions works through the backlog. Available logs are now about ~20mins old, and we expect to see that latency return to normal baseline in the next 2 hours.

8. resolved Jul 30, 2026, 10:38 PM UTC

   Ingestion lag is back at baseline

Read the full incident report →

Started Jul 07, 2026, 10:18 PM UTC· resolved Jul 07, 2026, 10:47 PM UTC

1. investigating Jul 07, 2026, 10:18 PM UTC

   We have detected node scaling issues in the Azure EastUS2 region and are currently investigating.

2. monitoring Jul 07, 2026, 10:46 PM UTC

   Engineers observe that affected clusters are returning to "healthy" status.

3. resolved Jul 07, 2026, 10:47 PM UTC

   The incident is fully resolved and all Azure clusters in EastUS2 are functioning as expected.

Read the full incident report →

Started Jul 06, 2026, 11:35 AM UTC· resolved Jul 06, 2026, 04:06 PM UTC

1. investigating Jul 06, 2026, 11:35 AM UTC

   We are investigating a spike in issues in AWS us-east-1 region, affecting node scale-up. This will create issues with workers scaling up and potentially new tasks starting

2. investigating Jul 06, 2026, 01:00 PM UTC

   AWS has published a status update for this issue. We are actively monitoring their progress and will continue to share updates.

3. monitoring Jul 06, 2026, 02:24 PM UTC

   AWS has now acknowledged a us-east-1 EC2 Launch Template API incident impacting EKS node provisioning/scaling (incl. Karpenter). We are continuing to monitor the situation.

4. monitoring Jul 06, 2026, 03:00 PM UTC

   We are no longer seeing any impacting clusters in the AWS us-east-1 region. We're continuing to monitor the situation.

5. resolved Jul 06, 2026, 04:06 PM UTC

   AWS has confirmed this incident is resolved.

Read the full incident report →

Started Jun 15, 2026, 11:27 PM UTC· resolved Jun 16, 2026, 12:53 AM UTC

1. investigating Jun 15, 2026, 11:27 PM UTC

   We are currently investigating this issue.

2. identified Jun 15, 2026, 11:28 PM UTC

   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

3. monitoring Jun 15, 2026, 11:34 PM UTC

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

4. resolved Jun 16, 2026, 12:53 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 15, 2026, 04:23 PM UTC· resolved Jun 15, 2026, 05:51 PM UTC

1. identified Jun 15, 2026, 04:23 PM UTC

   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.

2. monitoring Jun 15, 2026, 04:54 PM UTC

   We are monitoring the affect of the applied fix and are observing error rates coming down/ceasing for affected clusters.

3. resolved Jun 15, 2026, 05:51 PM UTC

   Mitigation was effective and all affected clusters are healthy.

Read the full incident report →

Started Jun 15, 2026, 04:23 PM UTC· resolved Jun 15, 2026, 05:51 PM UTC

1. identified Jun 15, 2026, 04:23 PM UTC

   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.

2. monitoring Jun 15, 2026, 04:54 PM UTC

   We are monitoring the affect of the applied fix and are observing error rates coming down/ceasing for affected clusters.

3. resolved Jun 15, 2026, 05:51 PM UTC

   Mitigation was effective and all affected clusters are healthy.

Read the full incident report →

Started May 08, 2026, 07:43 AM UTC· resolved May 09, 2026, 01:43 AM UTC

1. investigating May 08, 2026, 07:43 AM UTC

   We are currently observing elevated task failures and latency for some deployments running in the AWS us-east-1 region. This is related to an ongoing AWS incident affecting a single Availability Zone (use1-az4), where EC2 and EBS resources have experienced impairments. What to expect: You may see intermittent task failures or retries in your deployments. In most cases, these failures are transient and should self-resolve automatically as AWS continues recovery. What you should do: No immediate action is required. However, if you notice consistent or prolonged failures, please reach out to Astronomer Support, and we’ll help investigate further. We are continuing to monitor the situation closely and will share updates as needed. Refer: https://health.aws.amazon.com/health/status

2. monitoring May 08, 2026, 07:45 AM UTC

   We are continuing to monitor the situation as AWS works toward full recovery in the affected Availability Zone. At this time, we are seeing signs of stabilization, and most transient failures should continue to self-resolve. We will provide further updates once AWS confirms that the issue has been fully resolved.

3. resolved May 09, 2026, 01:43 AM UTC

   AWS has confirmed recovery in the affected Availability Zone (use1-az4), and system performance has returned to normal levels. We are no longer observing elevated task failures or latency in the AWS us-east-1 region. Any previously impacted workloads should now be operating as expected. If you continue to experience issues, please reach out to Astronomer Support for assistance.

Read the full incident report →

Started May 07, 2026, 10:31 AM UTC· resolved May 07, 2026, 02:24 PM UTC

1. investigating May 07, 2026, 10:31 AM UTC

   We are investigating delayed delivery for some time-based alerts. The delay is primarily visible for DAG Timeliness alerts, and may also affect Observe-related SLA, Proactive SLA, and Data Quality monitor alerts. DAG Duration and Task Duration alerts do not appear to be affected at this time.

2. identified May 07, 2026, 11:15 AM UTC

   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.

3. identified May 07, 2026, 12:57 PM UTC

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

4. monitoring May 07, 2026, 01:49 PM UTC

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

5. resolved May 07, 2026, 02:24 PM UTC

   The incident has been resolved.

Read the full incident report →

Started May 06, 2026, 07:56 PM UTC· resolved May 06, 2026, 08:05 PM UTC

1. investigating May 06, 2026, 07:56 PM UTC

   Attempting to access the dags page in the Airflow UI results in a 403 Forbidden error. This should not be affecting task execution.

2. resolved May 06, 2026, 08:05 PM UTC

   Our team has determined this only affects internal access, Astro end users are unaffected.

Read the full incident report →