Skip to main content
Subscribe to Astro release notes to receive updates via RSS, email, or Slack.
Astronomer is committed to continuous delivery of both features and bug fixes to Astro. To keep your team up to date on what’s new, this document will provide a regular summary of all changes released to Astro. Latest Astro CLI Version: 1.44.0 (Release notes) Latest Astro Runtime Version: 3.3-2 (Release notes) Latest Remote Execution Agent Version: 1.8.3 (Release notes)
​

​
Billing API added to the Astro v1 Labs API

LabsThis feature is in Labs.
Enterprise+ Organizations can now query Astro cost and usage data programmatically through the new List daily usage endpoint on the Astro v1 Labs API, which returns per-Deployment resource cost data with a FOCUS-formatted response option.It syncs from the same cost breakdown export that powers the Organization dashboard, so you can pull the data on a schedule instead of exporting it by hand. See Attribute Astro spend across teams to build a chargeback report from this data.
​

​
Cross-region disaster recovery for GCP dedicated clusters is generally available

Self-service cross-region disaster recovery (DR) for GCP dedicated clusters is now generally available. You can configure a primary and a secondary dedicated cluster in different GCP regions, and fail over with minimal downtime and data loss. After failover, Astro automatically enables synchronization in the reverse direction, so you can fail back once the primary region recovers.See Disaster recovery.

​
Task-level utilization metrics

Astro now shows CPU and memory utilization at the Dag, task, and task instance level in a new Resource Metrics tab in the Airflow UI, with task-to-worker mapping that ties resource use back to the Dag, task, task run, and time window. Use it to identify which tasks consume the most resources, which are likely causing out-of-memory errors, and which Dags are driving cost.This feature is available on Astro executor Hosted Runtime 3.1+ Deployments, and on Remote Execution 3.1+ Deployments using Remote Execution Agents 1.5.0+ and Helm chart 2.0.0+.See View task-level utilization metrics.
​

​
Try the new Astro experience

PreviewThis feature is in Preview.
Astro’s navigation now gives you a single view across your entire Organization instead of a single Workspace. Deployments, Dags, and Astro IDE projects all appear across Workspaces in one view, with Workspace context on every row. Filter to a specific Workspace when you need to, or work from the full picture across your Organization. Workspace, Organization, and personal settings now share a single settings layout.The homepage also surfaces:
  • Recently Failed Dags: An Organization-wide table of failing Dags, sorted by failure rate, with time-range filters. Each row shows the Workspace and Deployment, run history, and two actions: Investigate with Otto and Open in Airflow.
  • Jump Back In: A strip of recently visited Deployments, Dags, data products, and Astro IDE projects.
  • Favorite Deployments: An Organization-wide view of Deployment health with All, Healthy, and Hibernating status filters. Each card shows status, cluster and repository context, and four metrics: Dag Runs, Tasks, Worker CPU, and Worker Memory.
You can favorite Dags (Airflow 3.1+) and Deployments to pin them to the top of these views and filter to only your favorites.Enable the new experience from the banner in Astro. To switch back, go to Your Profile, click Edit next to Astronomer Labs, and turn off the Astro Next toggle. Switching between experiences doesn’t change your pipelines or configuration.
​

​
Test against an existing Deployment in the Astro IDE

PreviewThis feature is in Preview.
You can now test code in the Astro IDE against an existing Astro Deployment in your Workspace, instead of only an ephemeral test Deployment. Testing against an existing Deployment reuses its configuration, connections, and resources, and skips provisioning a new environment.When you attach a session to an existing Deployment, the Astro IDE deploys your session’s image and Dags to that Deployment, overwriting the image and Dags currently running there. The Deployment keeps its own connections, Airflow variables, environment variables, and resource configuration. Testing against an existing Deployment requires the workspace.deployments.create permission.See Test against an existing Deployment.
​

​
New Deployment analytics experience

PreviewThis feature is in Preview.
Astro now offers a new version of the Deployment analytics experience with expanded Airflow visibility, including API server and webserver metrics, Dag processor coverage, Kubernetes executor and KubernetesPodOperator coverage, parse time, and richer per-status and per-component breakdowns. The new experience also includes improved charting controls, multi-pool visibility, and analytics charts on the Deployments list.During the preview period, you can switch between the new and previous analytics experience from the Analytics page.See View metrics for Astro Deployments.
​

​
Additional improvements

  • Updated Astro infrastructure to improve reliability and performance.
​

​
Enable Sub-Second Pipelines

LabsThis feature is in Labs.
You can now enable Sub-Second Pipelines on Airflow 3.2+ Deployments that use the Astro executor. Sub-Second Pipelines pair the Astro executor with a dedicated event-driven Event Scheduler that picks up and dispatches API-triggered Dag runs in under a second and sustains approximately 1,000 Dag runs per minute, where the Celery executor queues and falls behind. Use them for high-throughput triggered workloads, on-demand inference, programmatic workflow invocation, and API-driven reverse ETL.Enable the Sub-Second Pipelines toggle on the Deployment, create a worker queue with the Sub-Second toggle on, and route your Dag’s tasks to that queue. Sub-Second Pipelines support API-triggered Dag runs only; runs triggered by cron schedules, timetables, asset and data-aware scheduling, or message queues continue to use the standard scheduler. You can confirm a run took the sub-second path from the Dag’s sub_second tag, the Sub-Second Metrics tab in the Airflow UI, the Event Scheduler logs, or the SLA Metrics API.See Enable Sub-Second Pipelines.
​

​
Review code with Otto

LabsThis feature is in Labs.
You can now use Otto to review your Airflow code automatically when you open a pull request or merge request. The Otto review action posts a sticky summary comment, adds inline comments where it finds issues, and offers commit suggestions where a concrete fix is available. Each review returns a structured verdict of approve, comment, or request_changes, with line-anchored findings rated high, medium, or low severity.Otto reviews changes against Astronomer compatibility knowledge, Airflow community standards, and your team’s conventions captured in Otto Memory, so it catches issues that generic code review misses. The action supports GitHub through a Marketplace action and GitLab through a CI/CD template and Docker image. You can also run a review on demand from the Astro CLI with astro otto --persona reviewer.See Review code with Otto.
​

​
Additional improvements

  • When you add the first IP address range to your organization’s IP access list, the Astro API now rejects the request with a 400 Bad Request error if your current IP address falls outside the submitted ranges, which prevents you from accidentally locking yourself out. The same protection applies when you add multiple ranges at once, and users with IP access list bypass permission can still add the first range even when their IP falls outside it. See Set up IP Access List.

​
Bug fixes

  • Fixed the SMTP connection form in the Astro UI so its fields map to the correct Airflow SMTP provider parameter keys. The SSL and TLS fields are now labeled Disable SSL and Disable TLS and map to disable_ssl and disable_tls, where setting a field to true disables that protocol and false allows it. The sender email field now maps to from_email instead of mail_from.
​

​
Investigate Dag failures with Otto

LabsThis feature is in Labs.
You can now use Otto to investigate Dag failures on Astro from the Astro UI, Astro alerts, or the Astro API. Each investigation produces a structured diagnosis with a root cause type, severity, suggested fix, and a checklist of Dag- and task-level checks, drawing on Airflow, Astro, and Astro Observe context. You can also ask Otto to investigate a Dag failure interactively in the Astro CLI.To investigate critical Dag failures automatically, pair a Dag failure alert’s Dag Trigger notification channel with a Dag that calls the investigation API, then route the diagnosis to Slack, a pull request, or an incident management system. You can also tailor investigations with Otto investigation guidance set at the Workspace or Deployment level.See Investigate with Otto.

​
Dag-level access control is generally available

Dag-level access control is now generally available. You can assign roles scoped to individual Dags within a Deployment to enforce least-privilege security and enable multiple teams to collaborate in a single Deployment without exposing Dags across team boundaries.Dag roles can be bound to Dags by Dag tag or Dag ID and assigned to users, Teams, and API tokens. Astro provides two default Dag roles, Dag Viewer and Dag Author, and you can create custom Dag roles with granular permissions.This feature requires Astro Runtime 3.1-12+ and an Enterprise plan. See Dag-level access control.
​

​
Additional improvements

  • The Basic section of Deployment details in the Astro UI now includes a Deployment Namespace row with copyable text, so you can retrieve a Deployment’s namespace without using the Astro CLI or API.
​

​
API server horizontal autoscaling

PreviewThis feature is in Preview.
You can now enable horizontal autoscaling for the Airflow API server on Airflow 3 Deployments. Autoscaling scales between a fixed minimum of two replicas and a configurable maximum from 2 to 10. Autoscaling works on all Airflow 3 Deployments, and supports the Astro, Celery, and Kubernetes executors.See Configure API server autoscaling.

​
Project-scoped connections and variables in the Astro IDE

PreviewThis feature is in Preview.
You can now link Workspace-level connections, Airflow variables, and environment variables to specific Astro IDE projects. Project-linked objects only affect that project’s ephemeral test Deployments, without affecting Deployments that aren’t started from the Astro IDE. You can also set value overrides per project, or auto-link a Workspace object to every Astro IDE project in a Workspace.See Make connections, Airflow variables, and environment variables available.

​
Migrate Airflow connections and variables to the Environment Manager

PreviewThis feature is in Preview.
You can now bulk migrate connections and Airflow variables from a Deployment’s Airflow metadata database into the Astro Environment Manager. Astro creates a Workspace environment object linked to the source Deployment, then removes the source object from the metadata database, so you can manage and reuse the object centrally without losing access on the source Deployment.See Migrate Airflow connections and variables from a Deployment.

​
Promote a Deployment environment object to the Workspace

PreviewThis feature is in Preview.
You can now promote a single Deployment-scoped connection, Airflow variable, environment variable, or metrics export to the Workspace level in the Astro Environment Manager. Astro keeps the source Deployment linked, so it continues to use the same values, and you can reuse the object on other Deployments or Astro IDE projects.See Promote a Deployment environment object to the Workspace.

​
Additional improvements

  • When you select one or more Deployments on the Astro UI DAGs page, the tag filter dropdown now shows only tags from those Deployments.
  • The workspace filter on the Astro Observe homepage now displays your current Workspace by default, matching the Workspace context the page is already using to query data.
  • The maximum threshold for the DAG Duration Astro Alert is now 7 days (604,800 seconds), up from 1 day.
  • You can now designate security contact email addresses for your organization, in addition to Organization Owners, to receive security notifications. See Configure security contacts.

​
Bug fixes

  • Fixed an issue where users with the Organization Observe Admin or Organization Observe Member role received a 403 error when accessing the Airflow /dags page on Astro Runtime 3.2-3 or later. These roles now include read access to Dag runs, Human-in-the-Loop details, and task instances.
  • Fixed an issue on slow or large Workspaces where the Astro Observe Recently Failed DAGs table could show stale paginated results with mismatched page contents and totals. The table now resets to the first page in that scenario. Failed run counts also now use Dag run end time when available, so they better match the selected time range.
​

​
Additional improvements

  • Organization, Workspace, and Deployment API token tables and details pages in the Astro UI now show a Last Rotated column and row, with the UTC timestamp of the most recent rotation. Tokens that have never been rotated display Never.
​

​
Additional improvements

  • Disaster recovery configuration and actions have moved from the cluster Details page to a dedicated Disaster Recovery tab on eligible cluster detail pages. Use this tab to view DR status, initiate failover or failback, and enable or disable DR. See Disaster recovery.
  • The lineage sidebar now includes an Alerts tab when you select an Airflow Dag or task asset. From this tab, you can view existing alerts for the asset, create Dag or task failure alerts pre-scoped to the selected context, and edit or delete alerts based on your existing permissions.
  • The Astro UI color mode toggle now persists your dark or light mode preference across page refreshes.

​
Bug fixes

  • Fixed an issue where AWS disaster recovery cluster creation through the Astro API incorrectly used the primary cluster’s SecondaryVpcCidr for the disaster recovery cluster secondary VPC CIDR. The API now correctly applies the DRSecondaryVpcCidr request value.
​

​
Introducing Otto, Astronomer’s data engineering agent

LabsThis feature is in Labs.
Otto is Astronomer’s data engineering agent, purpose built for Airflow and designed to get smarter every session. Use Otto to build pipelines, debug failures, investigate production incidents, and manage Airflow upgrades, grounded in Astronomer’s compatibility knowledge base and your team’s accumulated memory.Key capabilities include:
  • Exploration: Query your data warehouse, trace lineage, and profile tables without leaving the agent session.
  • Dag authoring: Describe what you need in natural language. Otto writes the Dag, configures connections, triggers a run, and iterates until it works. When something breaks during development, Otto pulls task logs, reads Dag source, inspects variables and connections, and traces through the failure to propose a fix.
  • Investigation: When a production Dag fails, ask Otto to pull the logs, analyze the failure, and propose a fix. Otto reads production task logs, run history, connections, and Dag source, then works through the diagnosis interactively with you.
  • Airflow upgrades: Otto analyzes your Dag fleet against Astronomer’s compatibility knowledge base, identifies what breaks, proposes specific code changes, and produces a prioritized plan. See Upgrade Airflow with Otto.
Access Otto from your terminal with astro otto, or in Astro through the Astro IDE.See Get started with Otto.

​
Enforce dedicated clusters for new Deployments

Organization Owners can now restrict new Deployments to dedicated clusters only. When you enable Enforce Dedicated Clusters, Astro rejects requests to create new Deployments on standard clusters, both in the Astro UI and through the Astro API. Existing Deployments on standard clusters continue to run without changes.See Enforce dedicated clusters for new Deployments.
​

​
Cross-region disaster recovery is generally available

Self-service cross-region disaster recovery (DR) for AWS dedicated clusters is now generally available. You can configure a primary and a secondary dedicated cluster in different AWS regions, and fail over with minimal downtime and data loss. After failover, Astro automatically enables synchronization in the reverse direction, so you can fail back once the primary region recovers.See Disaster recovery.

​
AWS VPC peering is generally available

Self-service VPC peering configuration for Astro dedicated clusters on AWS is now generally available. You can create VPC peering connections between an external AWS VPC and an Astro dedicated cluster directly from the Astro UI, without contacting Astronomer support.See AWS Networking: VPC Peering.

​
Additional improvements

  • You can now create Azure dedicated clusters in the southafricanorth region. See Astro Hosted resource reference.
  • The Dag access management page now shows an error when assigning or editing a Dag role for a user, team, or API token fails, replacing the previous silent-failure behavior. See Dag-level access control.
  • The Astro UI has an updated visual style to align with the Astronomer brand.

​
Bug fixes

  • Fixed an issue where configuring custom workload identity for Remote Execution Deployments on AWS and GCP could fail when workload identity options did not provide derived project or account data. The identity configuration flow now uses the cluster cloud provider account directly.
​

​
Blueprint in the Astro IDE

PreviewThis feature is in Preview.
Blueprint is now available in the Astro IDE. Blueprint is a template-based Dag authoring system that lets platform teams define reusable workflow templates in Python, while analysts, analytics engineers, and data scientists assemble those templates into production Dags through a visual builder and form-driven configuration — without writing Airflow code.Key capabilities include:
  • No-code Dag authoring: Drag blueprints onto a visual canvas, configure them through forms, and connect them to define dependencies.
  • Platform-defined templates: Platform teams write blueprints using the open-source airflow-blueprint library, encoding best practices, operational defaults, and guardrails.
  • Dag YAML generation: Blueprint produces plain YAML configuration files that live in your Git repository alongside your other project files.
  • Built-in testing: Start an ephemeral test Deployment directly from the IDE to validate individual tasks or full Dags before committing.
  • Blueprint versioning: Pin Dags to specific blueprint versions so existing workflows continue to work when a blueprint is updated.
See Blueprint.

​
Additional improvements

  • Clicking a failed Dag row on the Observe home page now navigates directly to the corresponding Asset Catalog details page. See Observe.
  • You can now copy an alert ID directly from the actions menu in the Alerts list. See Alerts.
  • The Dag API tokens table in Dag access management now supports search, making it faster to locate specific tokens. See Dag-level access control.
  • The Ask Astro web application has been removed from Astro.
​

​
Additional improvements

  • The universal metrics exporter now scrapes metrics from triggerer, webserver, and apiserver components in addition to base, worker, scheduler, and Dag processor containers. These metrics are available automatically without additional configuration. See Export metrics.
  • Observe event timelines now include a Run ID column and display indented task and dataset events under their parent Dag events, making it easier to scan and correlate related timeline activity.
  • Clicking a Dag start, success, or failure event in the Observe timeline now opens the corresponding Airflow run page directly in a new tab.

​
Bug fixes

  • Fixed an issue where updating environment variables, changing the default Pod size, or editing executor settings on non-development Deployments returned the error Hibernation spec is not allowed for non-development deployments. This was caused by an empty hibernationSpec object stored in the Deployment’s scaling configuration data.
​

​
API token access management pages

You can now click an API token’s row in the Astro UI to open a dedicated access management page for Workspace and Deployment API tokens. From these pages, you can view token details and manage applicable roles, including Deployment roles and Dag roles, without navigating away from the token context.See Workspace API tokens and Deployment API tokens.

​
Self-service user profile updates

You can now update your user profile directly from the Astro UI. Users managed by an Identity Provider (IdP) can update profile preferences but cannot edit name fields, which are managed by the IdP.

​
Self-service disable Disaster Recovery

You can now disable Disaster Recovery (DR) for eligible clusters directly from the cluster actions menu in the Astro UI.See Set up disaster recovery.

​
Custom GCP workload identity at Deployment creation

You can now specify a custom workload identity for eligible GCP Deployments at creation time, instead of configuring it after Deployment creation.See Authorize deployments to cloud resources.

​
Additional improvements

  • Cluster details in the Astro UI now display the GCP Project Number for GCP clusters. You can copy this value directly from the cluster details page.

​
Bug fixes

  • Fixed a 500 error that occurred when Git deployments to Astro used a trailing slash in the Astro project path.
  • Fixed an issue where dbt bundle deletion failed when the object version ID was missing from cloud storage metadata.
  • Fixed an issue where Airflow variable values and value overrides in the Astro UI required a non-empty value. You can now create or update Airflow variables with empty values.
  • Fixed missing Airflow 3 metric exports for scheduler heartbeat, triggerer heartbeat, task heartbeat kill, and asset metrics. These metrics are now available in telemetry output.
  • Fixed an issue where clicking Open Airflow in the Astro UI also navigated the current page to Deployment details. The button now only opens Airflow in a new tab.
  • Fixed an issue where the alert edit page in the Astro UI showed stale values after saving changes. The page now reflects updates immediately without a manual refresh.
​

​
Async sessions and session history in the Astro IDE

PreviewThe Astro IDE is in Preview.
Sessions in the Astro IDE are no longer tied to an open browser tab. You can submit a prompt, close the browser, and return later to see the completed response. The AI agent continues processing in the background.Key changes include:
  • Async processing: After submitting a prompt, you can navigate away and return later to see the completed response.
  • Session history: The Sessions tab shows a chronological list of your past sessions. Click any session to resume it with full context.
  • Session persistence: Conversation data is stored in cloud object storage and can be fully restored at any time.
  • Private sessions: Sessions are private to the user who created them, while projects remain shared across the Workspace.

​
Underlying Data tab and updated cost categories in Organization Dashboards

Organization Dashboards now include an Underlying Data tab with raw data tables in a standardized financial format for Deployment activity, Workspace activity, and daily cost breakdowns. You can filter, download, email, and schedule exports directly from these tables. The Cost Breakdown dashboard also now includes additional cost categories and a new Detailed Costs view with granular breakdowns by Deployment, Compute Types, Worker Queues, or Clusters.See Export and schedule Organization Dashboard data and Organization Dashboard.

​
Smaller VPC subnet support for AWS clusters

You can now create dedicated clusters on AWS with a VPC subnet range as small as /22, down from the previous minimum of /21. This gives you more flexibility to configure cluster networking with smaller address spaces when a full /21 block isn’t available.See Create a dedicated Astro cluster.

​
GCP europe-west3 (Frankfurt) region support for standard clusters

You can now create standard deployments in the GCP europe-west3 (Frankfurt, Germany) region.
​

​
Cross-region disaster recovery for AWS dedicated clusters now in Preview

PreviewThis feature is in Preview.
You can now configure cross-region disaster recovery (DR) for AWS dedicated clusters. DR lets you pair a primary and secondary cluster in different AWS regions so you can fail over with minimal downtime and data loss if a full region outage occurs.Key capabilities include:
  • Self-service failover and failback from the Astro UI.
  • Automatic replication of Deployments, Dag run history, task instance metadata, environment variables, connections, Airflow variables, and task logs to the secondary cluster.
  • Recovery time objective (RTO) of less than one hour and recovery point objective (RPO) of less than 15 minutes with the optional Task Logs Replication SLA.
  • All hostnames, including Airflow UI, Airflow API, and Remote Execution API URLs, are automatically updated to point to the active cluster after failover.
Cross-region DR requires the Enterprise Business Critical tier. You can enable DR when creating a new dedicated cluster or submit a support request to enable it on an existing cluster. See Disaster recovery.

​
Improved authentication resilience

Astro now runs authentication services directly in each data plane, removing the dependency on a single-region control plane component for authenticating requests. This reduces the affected area of control plane incidents, so your Deployments remain accessible even when parts of the control plane are unavailable.Deployment URLs now route directly through the data plane. Old URLs continue to work and automatically redirect for 6-12 months. If you have strict network allowlists or custom networking configurations, Astronomer will contact you with guidance on any required updates.

​
Direct access Deployment API tokens

You can now create direct access Deployment API tokens that authenticate requests directly at the Deployment level without depending on the control plane. During a control plane outage, Dags and automations that use direct access tokens continue to access the Airflow API without interruption.Direct access tokens are available to Organization Owners through the Astro UI when creating a Deployment API token. The role assigned to a direct access token cannot be changed after creation. See Deployment API tokens.
​

​
Additional improvements

  • Updated Astro infrastructure to improve reliability and performance.
​

​
Dag-level access control now in Labs

LabsThis feature is in Labs. Reach out to your account team to enable this feature.
You can now assign roles scoped to individual Dags within a Deployment. Dag-level access control lets you enforce least-privilege security and enable multiple teams to collaborate in a single Deployment without exposing Dags across team boundaries.Dag roles can be bound to Dags by DAG Tag or DAG ID and assigned to users, Teams, and Organization API tokens. Astro provides two default Dag roles, Dag Viewer and Dag Author, and you can create custom Dag roles with granular permissions.This feature requires Astro Runtime 3.1-12+ and an Enterprise plan. See Dag-level access control.

​
Additional improvements

  • Added support for AWS PrivateLink and Azure Private Link to enable private connectivity between Astro clusters and customer-managed Remote Execution Agents.
​

​
Additional improvements

  • Updated Astro infrastructure to improve reliability and performance.

​
Bug fixes

  • Fixed an issue where the event timeline in the lineage graph did not correctly filter events based on the before time selection.
​

​
New GCP regions available for dedicated clusters

You can now create dedicated clusters in the following GCP regions:
  • northamerica-northeast2
  • southamerica-west1
  • australia-southeast2

​
Additional improvements

  • Added an optional Description field to all environment manager objects, including Connections, Environment Variables, Airflow Variables, and Metrics Exports.
  • In the Astro IDE, you can now include whole directories in chat context instead of selecting files individually, improving bulk operations and multi-file questions.

​
Bug fixes

  • Fixed an issue where the Extra field in the Astro connection manager used a text input instead of a JSON editor, causing errors like TypeError: 'str' object does not support item assignment when setting JSON session parameters on connections.
  • Fixed incorrect dag duration metrics caused by duplicate events.
  • Fixed Run History date range filtering to include long-running runs that started within the selected range but spanned beyond the end date.
​

​
Astro API v1 now generally available

The Astro API v1 is now generally available. The v1 API provides a production-ready API with coverage under standard Astronomer support SLAs. The previous v1beta1 API is deprecated and will reach end of support in January 2027. See the v1beta1 deprecation notice and migration guide for details.

​
Pre-emptive migrations to shorten Airflow 2 to Airflow 3 upgrades

Shortened the duration of future in-place Airflow 2 to Airflow 3 upgrades by executing a database migration and preparation across all Airflow 2 Deployments. This applies only to Astro Runtime 12 and 13, as those are the minimum versions required to upgrade to Airflow 3 and Astro Runtime 3. All Runtime versions below 12 are deprecated. Once you upgrade from a deprecated version to Runtime 12 or 13, the pre-emptive migration will be executed. In some cases, this optimization has reduced in-place Airflow 2 to Airflow 3 upgrade times from hours to minutes.

​
Bug fixes

  • Fixed an issue where Deployments remained stuck in the Deploying state if a worker queue name contained Airflow component keywords such as “scheduler.”
​

​
Astro Observe data quality now in Preview

PreviewThis feature is in Preview.
Astro Observe data quality for Snowflake and Databricks is now available in Preview. Data quality helps you monitor tables and columns for data quality issues including row volume changes, schema changes, and null columns, alerting on issues and displaying upstream and downstream table-level lineage to help keep your data accurate and complete.See data quality for setup and more information.

​
Additional improvements

  • Astro Observe SLAs now support flexible cron-based schedules to capture complex business logic and allow more control over SLA sensitivity.
​

​
Additional improvements

  • Organization Owners can now manage API token assignments and roles from the API Token Details page. You can now add an API token to a Workspace or Deployment, update an API token’s role within a Workspace or Deployment, and remove an API token from a Workspace or Deployment directly from Organization Settings -> Access Management -> API Tokens.
​

​
Additional improvements

  • You can now view the details and roles assigned to an API token by clicking on any token in the Organization Settings -> Access Management -> API Tokens table, which opens the new API Token Details page.

​
Previous years