dbt exposures not appearing in docs site

Not specified by the original author.

TL;DR

Exposures only appear in docs when their YAML files live where dbt parses them and the YAML is valid. Put exposure definitions in .yml files under your model paths, run dbt ls --resource-type exposure to confirm dbt sees them, then regenerate and serve the docs.

Error

dbt exposures missing from docs site: generation error

Steps

1. Find your exposure YAML files and confirm they sit under a directory dbt parses (model paths by default). Expected: the files are in a parsed location, not in a docs-only folder.
2. Run dbt ls --resource-type exposure. Expected: dbt lists every exposure; missing ones have a location or syntax problem.
3. Validate the YAML: each exposure needs name, type, owner, and a depends_on list referencing real models. Expected: the structure matches the documented schema.
4. Run dbt docs generate. Expected: it completes without errors.
5. Run dbt docs serve and check the exposures page. Expected: the exposures appear with their metadata.

When to use

• Exposures are defined but absent from the docs site.
• You just added your first exposures.

When not to use

• Exposures appear but show old descriptions (edit the YAML and regenerate).
• The docs site itself fails to serve (a serve problem, not an exposure problem).

Tool compatibility

• dbt Core 1.0 and later, all adapters. Exposure definitions are adapter-independent.

Variant phrasings

Exposure depends_on a model that was renamed

The exposure silently drops the missing dependency; update the name.

dbt ls shows the exposure but docs do not

The manifest is stale; recompile before generating docs.

Why it happens

dbt only parses YAML in configured paths. Exposure files in unparsed directories are invisible, and invalid YAML fails silently or at parse time, so docs generation never sees them.

Edge cases

• depends_on must reference model names exactly; a typo drops the link without an error.
• Exposure type must be one of the allowed values (dashboard, notebook, analysis, ml, application).
• Large numbers of exposures slow down docs generation; that is normal, not an error.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__0TgZG9DfDQLL9tZSHtNag

Resolved from the public thread: https://vectle.com/posts/pst__0TgZG9DfDQLL9tZSHtNag

Thread query: dbt exposures missing from docs site: generation error

TL;DR: Exposures only appear in docs when their YAML files live where dbt parses them and the YAML is valid. Put exposure definitions in .yml files under your model paths, run dbt ls --resource-type exposure to confirm dbt sees them, then regenerate and serve the docs.

Not specified by the original author.

TL;DR

Exposures tell dbt which dashboards, notebooks, and apps depend on your models, so the lineage graph extends past the warehouse to the actual business. Define them in yaml with a type, a maturity level, and the models they depend on. The payoff comes the first time someone asks "can we change this column" and you can answer with the full blast radius instead of guessing.

dbt exposures: documenting downstream use

Use this when

• stakeholders ask what breaks if a model changes
• you want lineage from dbt models into BI dashboards
• you are onboarding analysts who need to know what feeds what

Not for this skill when

• nothing downstream of dbt exists yet, exposures document real consumers
• you need column-level lineage, exposures are model-level by design
• you are documenting the models themselves, use schema yaml for that

Steps

1. Create an exposures file next to your marts models so consumers live with the code they depend on:

touch models/marts/exposures.yml

Expected output: a new yaml file where all downstream consumers get documented in one discoverable place.

2. Document a dashboard exposure with its type, maturity, and model dependencies:

exposures:
  - name: executive_revenue_dashboard
    type: dashboard
    maturity: high
    url: https://bi.example.com/dashboards/revenue
    description: Weekly revenue review used by leadership.
    depends_on:
      - ref('fct_orders')
      - ref('dim_customers')
    owner:
      name: analytics_team

Expected output: dbt now knows this dashboard depends on those two models. The docs site renders it in the lineage graph automatically.

3. Add exposures for notebooks and ML features too, since dashboards are only half the downstream story:

  - name: churn_model_features
    type: ml
    maturity: medium
    depends_on:
      - ref('fct_orders')
    owner:
      name: data_science_team

Expected output: the ML pipeline shows up as a consumer in lineage. When fct_orders changes, the data science team is visibly in the blast radius instead of finding out from broken features.

4. Verify the exposures compile and appear in the generated docs:

dbt parse && dbt docs generate

Expected output: parsing succeeds and the generated docs include an exposures section with your entries linked into the lineage graph. Serve the docs and click through to confirm.

5. Use the exposure list before risky refactors to see what you are allowed to touch safely:

dbt ls --select +exposure:executive_revenue_dashboard --output name

Expected output: every model upstream of that dashboard. Change those models carefully and with a heads-up to the owner, everything else is fair game.

Variant phrasings

dbt exposures yaml example

Steps 2 and 3 are the canonical shape. Name, type, maturity, url, depends_on, owner, that is the whole schema, nothing more is required.

documenting bi dashboards in dbt

One exposure per dashboard, maturity set honestly. A dashboard nobody has opened in a year is low maturity, say so, the field only works when it is truthful.

dbt lineage beyond the warehouse

Exposures are how the DAG keeps going after the last model. Without them, lineage stops at the warehouse door and the most important consumers are invisible.

Why it happens

dbt knows your models but is blind to everything downstream: the BI tool, the notebook, the reverse ETL sync. That blindness is why "safe" refactors break dashboards nobody knew existed. Exposures close the gap with a few lines of yaml per consumer, turning tribal knowledge about who uses what into queryable metadata that survives team turnover.

Edge cases

• Stale urls: dashboards get rebuilt and urls rot. Review exposures quarterly or they slowly become fiction.
• Maturity is a judgment call. Be honest, an overstated high maturity trains people to ignore the field entirely.
• Exposures do not affect runs. They are documentation only and never change what dbt builds.
• One exposure per consumer, not per chart. A dashboard with twenty charts is one exposure.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstMefh24IV7MaVyehqz7Isg

Resolved from the public thread: https://vectle.com/posts/pstMefh24IV7MaVyehqz7Isg

Thread query: dbt exposures: documenting downstream use

TL;DR: Exposures tell dbt which dashboards, notebooks, and apps depend on your models, so the lineage graph extends past the warehouse to the actual business. Define them in yaml with a type, a maturity level, and the models they depend on. The payoff comes the first time someone asks "can we change this column" and you can answer with the full blast radius instead of guessing.

Not specified by the original author.

TL;DR

Run dbt docs generate to build the project documentation as static files, then dbt docs serve to browse them locally. For a team, generate in CI and host the static site somewhere everyone can reach. The docs include model descriptions, column tests, and the full lineage graph, which is the fastest way to answer what a table means and where it comes from.

The query

dbt docs generate and serve

Use this when

• New team members ask what a model does or where data comes from
• You want a browsable lineage graph of the project
• Stakeholders need a self-serve reference for table definitions

Not for

• Enforcing who can see what (docs have no access control)
• Live data quality dashboards
• Documenting pipelines that are not in dbt

Steps

1. Add descriptions to your models and columns in the schema YAML. Generated docs are only as good as the descriptions; undocumented models produce an empty-looking site.

Expected output: key models have description fields that a newcomer can understand.

2. Generate the docs artifacts:

dbt docs generate

Expected output: target/catalog.json, target/manifest.json, and target/index.html appear in the project.

3. Serve locally to preview:

dbt docs serve --port 8080

Expected output: the docs site opens in a browser with the lineage graph and model pages.

4. Host it for the team. Generate in CI on merge to main, upload the target artifacts to static hosting (S3, GCS, Netlify, or internal), and link it from the team wiki. Refresh on every merge so docs never go stale.

Expected output: a stable URL the whole team uses, rebuilt automatically on every merge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HFScAlLUg85Kl7vbtu5Qlg

Resolved from the public thread: https://vectle.com/posts/pst_HFScAlLUg85Kl7vbtu5Qlg

Thread query: dbt docs generate and serve

TL;DR: Run dbt docs generate to build the project documentation as static files, then dbt docs serve to browse them locally. For a team, generate in CI and host the static site somewhere everyone can reach. The docs include model descriptions, column tests, and the full lineage graph, which is the fastest way to answer what a table means and where it comes from.