---
title: "MDLH: Accelerate root cause analysis"
url: "https://atlan.com/demos/mdlh-accelerate-root-cause-analysis/"
excerpt: "Trace any broken dashboard to its upstream culprit in seconds — with owners, certification status, and connector context attached."
description: "Replace the ten-minute click-through of lineage nodes during a live incident with a single SQL query that maps the full upstream dependency chain. Get every contributing asset ranked by distance from the problem, with the metadata signals that matter most — certification gaps unexpected connectors, missing owners — right there in the results. Resolve faster, share findings instantly, and have a repeatable playbook for the next time something breaks."
format: "Video"
duration: "PT4M56S"
video: "https://videos.ctfassets.net/nwa1c00rtgxb/5sYs8ssUtklbqJqrzPe7Fd/37317c9b8437ea258b67ec16c8b3f4f0/MDLH_-_Accelerate_root_cause_analysis.mp4"
thumbnail: "https://images.ctfassets.net/nwa1c00rtgxb/1yc5V5GBmSDbC8RGmtGApW/e9b72ac8793a17083957eb5c00f03af2/mdlh-accelerate-root-cause-analysis.webp"
content_purpose: ["Product Overview"]
target_persona: ["General", "Data Engineer", "Data Analyst"]
journey_stage: ["S2 - Discovery", "S3 - Solution Design", "S4 - Business Case", "C1 - Onboarding", "C2 - First Value", "C3 - Adoption"]
use_case_context: ["Training"]
product: ["Enterprise Data Graph - Data Lineage"]
published: "2026-03-13"
updated: "2026-06-02"
content_type: "video transcript"
transcript_source: "sheet"
---

# MDLH: Accelerate root cause analysis

Transcript of the video at https://atlan.com/demos/mdlh-accelerate-root-cause-analysis/

A dashboard just broke. You've been clicking upstream through the lineage graph for ten minutes and still don't know which table is the problem or who owns it. One query surfaces all of it. We've all been on those calls: dashboard down, everyone watching, and the data engineer is three hops deep in the lineage graph — clicking node to node, switching to a separate panel to check ownership, taking screenshots because there's nothing to export. The lineage data exists. The ownership data exists. They're just not queryable together. This query puts ownership, certification status, and lineage depth in the same row.

Atlan’s lineage graph is a strong starting point for root cause analysis. We can expand upstream from any asset, read ownership and certification status at a glance, and export the current view as a table — which covers most shallow investigations. Where it falls short is scale and customisation. The export columns are fixed, so we can’t adjust what metadata we’re looking at without downloading and manually manipulating. In a deep pipeline with multiple hops, clicking through level by level takes significantly longer — and we still end up with something we can’t filter, re-run, or easily share when the next asset breaks.

When we need a structured, repeatable trace across a full upstream dependency chain — with ownership, certification status, and quality flags all in one view — we need the lineage graph to be queryable. A single SQL query against the Metadata Lakehouse replaces that entire process. Give it the GUID of any broken asset and it traverses the full upstream dependency chain — returning every contributing asset ranked by distance from the problem, with owners and certification status already attached. Let’s walk through each step. were starting in Atlan's lineage graph, which is already have a strong tool.

We can expand upstream from any asset, expand to see dependencies and understand ownership and data quality signals, and get a quick read on what's directly above the problem. We can even show this in a table format quickly by clicking on the export option. But the graph is built for exploration one click at a time and the output is static, we can’t add different metadata columns for each asset for our use case. When the pipeline is deep, or when we need to share findings with someone else with key additional metadata— that's where the Lakehouse query earns its place.

To run it, we need one thing from the broken asset. For this query, we start with the problematic asset and retrieve its GUID. It's the long alphanumeric string we'll use to anchor the query. With that in hand, let's run the trace. Our query traverses the full upstream dependency chain for any downstream asset — pulling together lineage relationships and metadata for each asset it encounters along the way. By default, we trace five hops back through the pipeline — which covers most production architectures. We can increase that depth if our stack runs deeper.

Here's what makes this different from the UI: the query returns certification status and owner information together, for every asset in the chain, in a single result set, but is flexible to provide any additional metadata information that helps your team. We're not clicking through levels and combining multiple exports for the right metadata — we're scanning a table. If hop 3 has an uncertified table owned by a team you've never heard of, we see it immediately. Let’s read through the output and find the culprit. The results come back ordered by distance from the problem — direct parents first, then grandparents, and so on.

We look for patterns: an uncertified asset at hop 2, an asset sourced from an unexpected connector, or an upstream table with no owner assigned. A good starting point: if an asset at hop 1 or hop 2 shows a deprecated certification status or data quality issue or announcement, that's our prime suspect. The connector information tells we which source system each asset comes from — so if a Databricks table at hop 3 is deprecated and has an announcement, we now have a key candidate for the root cause. Now let's act on it.

With owner information already in the results, we have who to contact. We don't need to navigate back into Atlan to find the asset and look up its owner — it's right there in the output. We can reach out directly, or use the GUID to navigate straight to that asset in Atlan and leave and create a slack message to the owner. That's the full investigation — from broken dashboard to culprit, with a clear path to resolution. We now have a repeatable query that takes any downstream asset and maps the full upstream dependency chain — with owners, certification status, and connector context attached.

The UI is still our starting point for fast visual orientation. The query is what we reach for when we need answers fast and need to act on them. If we want to see the other side of this — how to proactively check downstream impact before you make a change so you're not in root cause mode in the first place — that walkthrough is linked right here.
