Astronomer Outage History
Astronomer is up right nowPingoru has recorded 65 incidents for Astronomer: 64 in the last 12 months and 18 in the last 90 days.
Show as a table
| Month | Incidents | Hours with an open incident |
|---|---|---|
| April 2026 | 13 | 36 of 720 (5%) |
| May 2026 | 8 | 31 of 744 (4%) |
| June 2026 | 4 | 3 of 720 (0%) |
| July 2026 | 3 | 12 of 744 (2%) |
| August 2026 | 4 | 324 of 744 (43%) |
| September 2026 | 5 | 38 of 720 (5%) |
| October 2026 | 8 | 250 of 536 (47%) |
Incidents, newest first
Major October 20, 2026 Delayed delivery of Astro Alerts 1d 2h
Started Oct 20, 2026, 06:40 AM UTC· resolved Oct 21, 2026, 08:49 AM UTC
- 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.
- 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.
- 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.
- 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.
- 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.
Major October 19, 2026 Organization Dashboards are failing to load with Invalid kid parameter error 1h 23m
Started Oct 19, 2026, 09:37 AM UTC· resolved Oct 19, 2026, 11:00 AM UTC
- 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.
- 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.
- resolved Oct 19, 2026, 11:00 AM UTC
The issue has been resolved, and the Organization Dashboards are now working as expected.
Major October 13, 2026 Astro UI and API are appearing offline for some users 1h 51m
Started Oct 13, 2026, 06:02 PM UTC· resolved Oct 13, 2026, 07:53 PM UTC
- 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.
- 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.
- 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.
- 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.
Minor October 6, 2026 Capacity constraints in GCP us-central1 may delay or fail some task executions 7d 21h
Started Oct 06, 2026, 03:33 AM UTC· resolved Oct 14, 2026, 12:34 AM UTC
- 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. We are working to address the issue and keep this page posted as we have more updates.
- 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.
Minor October 3, 2026 Dag success/failure Astro Alert emails missing deployment & workspace names 56m
Started Oct 03, 2026, 08:42 PM UTC· resolved Oct 03, 2026, 09:39 PM UTC
- 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.
- identified Oct 03, 2026, 09:03 PM UTC
Correction: Deployment and Workspace _names_ are not populated, earlier update cited IDs incorrectly.
- monitoring Oct 03, 2026, 09:13 PM UTC
We have reverted the problematic email template changes and are continuing to monitor for full resolution.
- resolved Oct 03, 2026, 09:39 PM UTC
All Astro Alert emails for Dag Success/Failure now correctly include the deployment/workspace name.
Critical October 1, 2026 Tasks getting stuck in the queued state and failing 1h 7m
Started Oct 01, 2026, 10:40 PM UTC· resolved Oct 01, 2026, 11:47 PM UTC
- 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.
- 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.
Major September 24, 2026 Astro UI Deployment view unavailable 41m
Started Sep 24, 2026, 02:52 PM UTC· resolved Sep 24, 2026, 03:34 PM UTC
- 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.
- investigating Sep 24, 2026, 02:56 PM UTC
We have confirmed that task execution is unaffected. We're continuing to investigate.
- 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.
- 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.
Major September 17, 2026 Permissions silently dropped from custom roles 3h 56m
Started Sep 17, 2026, 05:54 PM UTC· resolved Sep 17, 2026, 09:50 PM UTC
- 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.
- monitoring Sep 17, 2026, 07:29 PM UTC
All custom roles have been restored to their previous functionality and full operation has been restored.
- resolved Sep 17, 2026, 09:50 PM UTC
No further issues have been found, so this is being marked as resolved.
Major September 8, 2026 Tasks remain in the queued state on some worker queues. 7h 35m
Started Sep 08, 2026, 12:33 PM UTC· resolved Sep 08, 2026, 08:09 PM UTC
- 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.
- monitoring Sep 08, 2026, 07:42 PM UTC
A fix has been implemented, and we are monitoring the results.
- resolved Sep 08, 2026, 08:09 PM UTC
The incident has been resolved.
Major September 4, 2026 Increased auth errors 2h 58m
Started Sep 04, 2026, 03:08 AM UTC· resolved Sep 04, 2026, 06:07 AM UTC
- 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.
- 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.
- identified Sep 04, 2026, 04:52 AM UTC
The potential root cause identified, and fix is underway
- 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.
- 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.
Minor September 1, 2026 Potential impact to Astro deployments in GCP us-central1 3h 49m
Started Sep 01, 2026, 06:40 PM UTC· resolved Sep 01, 2026, 10:29 PM UTC
- 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](https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev "Google Cloud status incident").
- 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](https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev "Google Cloud status incident").
- 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](https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev "Google Cloud status incident").
- 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](https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev "Google Cloud status incident").
- 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.
- 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.
- resolved Sep 01, 2026, 10:29 PM UTC
The GCP incident is marked as Closed officially
Notice August 18, 2026 Incorrect scheduler heartbeat metrics being reported 23d 3h
Started Aug 18, 2026, 06:51 PM UTC· resolved Sep 10, 2026, 10:19 PM UTC
- investigating Aug 18, 2026, 06:51 PM UTC
Our metrics pipeline is falsely displaying spikes in scheduler heartbeat metrics, despite underlying component health.
- 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.
- resolved Sep 10, 2026, 10:19 PM UTC
This issue is now resolved.
Major August 18, 2026 Intermittent task instances failures. 3h 18m
Started Aug 18, 2026, 04:17 AM UTC· resolved Aug 18, 2026, 07:36 AM UTC
- 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.
- monitoring Aug 18, 2026, 04:18 AM UTC
Fix is being rolled out across all astro deployments.
- resolved Aug 18, 2026, 07:36 AM UTC
Rollout has been completed
Minor August 4, 2026 KPO podspec changes for GPU-enabled nodes may cause KPO pod startup failures 1h 29m
Started Aug 04, 2026, 03:11 PM UTC· resolved Aug 04, 2026, 04:40 PM UTC
- 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.
- 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.
- 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.
Minor August 4, 2026 Intermittent Delays Managing Airflow Deployments in Azure Central US 1h 38m
Started Aug 04, 2026, 12:57 PM UTC· resolved Aug 04, 2026, 02:36 PM UTC
- 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.
- 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.
- resolved Aug 04, 2026, 02:36 PM UTC
This interruption has been resolved.
Minor July 30, 2026 Platform Log ingestion issue 6h 35m
Started Jul 30, 2026, 04:02 PM UTC· resolved Jul 30, 2026, 10:38 PM UTC
- 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.
- 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.
- 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.
- identified Jul 30, 2026, 06:43 PM UTC
We are continuing to investigate and monitor this issue.
- 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
- 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.
- 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.
- resolved Jul 30, 2026, 10:38 PM UTC
Ingestion lag is back at baseline
Minor July 7, 2026 Node Scaling Issue in Azure EastUS2 Region 28m
Started Jul 07, 2026, 10:18 PM UTC· resolved Jul 07, 2026, 10:47 PM UTC
- investigating Jul 07, 2026, 10:18 PM UTC
We have detected node scaling issues in the Azure EastUS2 region and are currently investigating.
- monitoring Jul 07, 2026, 10:46 PM UTC
Engineers observe that affected clusters are returning to "healthy" status.
- resolved Jul 07, 2026, 10:47 PM UTC
The incident is fully resolved and all Azure clusters in EastUS2 are functioning as expected.
Major July 6, 2026 Node Scaling issues in AWS us-east-1 region 4h 30m
Started Jul 06, 2026, 11:35 AM UTC· resolved Jul 06, 2026, 04:06 PM UTC
- 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
- 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.
- 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.
- 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.
- resolved Jul 06, 2026, 04:06 PM UTC
AWS has confirmed this incident is resolved.
Minor June 16, 2026 Azure clusters may experience issues with worker scale up and task pod scheduling 47m
Started Jun 16, 2026, 12:05 AM UTC· resolved Jun 16, 2026, 12:53 AM UTC
- identified Jun 16, 2026, 12:05 AM 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
- monitoring Jun 16, 2026, 12:05 AM UTC
A fix has been implemented and we are monitoring the results.
- investigating Jun 16, 2026, 12:05 AM UTC
We are currently investigating this issue.
- resolved Jun 16, 2026, 01:07 AM UTC
This incident has been resolved.
Notice June 15, 2026 astro deploys not reflecting on certain Astro clusters 1h 27m
Started Jun 15, 2026, 04:23 PM UTC· resolved Jun 15, 2026, 05:51 PM UTC
- 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.
- 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.
- resolved Jun 15, 2026, 05:51 PM UTC
Mitigation was effective and all affected clusters are healthy.
Minor May 8, 2026 Increased Task Failures in US-East-1 (AWS) - AWS Incident 17h 37m
Started May 08, 2026, 08:06 AM UTC· resolved May 09, 2026, 01:43 AM UTC
- monitoring May 08, 2026, 08:06 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.
- investigating May 08, 2026, 08:06 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
- resolved May 09, 2026, 02:07 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.
Minor May 7, 2026 Delayed delivery for some time-based alerts 3h 16m
Started May 07, 2026, 11:08 AM UTC· resolved May 07, 2026, 02:24 PM UTC
- investigating May 07, 2026, 11:08 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.
- identified May 07, 2026, 12:08 PM 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.
- identified May 07, 2026, 01:06 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.
- monitoring May 07, 2026, 02:07 PM UTC
A fix has been implemented, and we are monitoring the results.
- resolved May 07, 2026, 03:08 PM UTC
The incident has been resolved.
Major May 6, 2026 Deployments on Astronomer Runtime 3.2-3 are returning 403 errors when accessing dags page. –
Started May 06, 2026, 08:05 PM UTC· resolved May 06, 2026, 08:05 PM UTC
- investigating May 06, 2026, 08:05 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.
- resolved May 06, 2026, 09:05 PM UTC
Our team has determined this only affects internal access, Astro end users are unaffected.
Major May 4, 2026 Dashboard cost breakdown data delays 9h 6m
Started May 04, 2026, 11:09 AM UTC· resolved May 04, 2026, 08:15 PM UTC
- investigating May 04, 2026, 11:09 AM UTC
We’re investigating an issue affecting Dashboard cost breakdown data. For affected customers, cost breakdown information may appear stale and may not have updated since May 1, 2026. Our team is actively investigating the cause and working to restore current data. We’ll share another update as we have more information.
- investigating May 04, 2026, 11:09 AM UTC
We are continuing to investigate this issue.
- resolved May 04, 2026, 09:08 PM UTC
This incident is now resolved, and all Cost Breakdown data is now up to date. The issue that caused the delay has been fixed and should not recur.
Major April 27, 2026 Airflow UI showing 403s for some customers 2h 9m
Started Apr 27, 2026, 10:06 PM UTC· resolved Apr 28, 2026, 12:16 AM UTC
- investigating Apr 27, 2026, 10:06 PM UTC
It seems to be only in AWS clusters for now. We have a workaround we can apply while we investigate.
- investigating Apr 27, 2026, 10:06 PM UTC
We are continuing to investigate this issue.
- resolved Apr 28, 2026, 01:06 AM UTC
We rolled back a change we made to our authentication system. Any image pushes or config changes to a deployment that occurred after our rollback caused the deployment to fix itself, which is why so many people found their 403s resolved themselves after some time.