Dagster+ (Dagster Cloud)
Let AI connect your sources for you
Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.
Connect Dagster+ (Dagster Cloud) to PostHog to sync your data into the PostHog data warehouse for analysis and modeling.
Connect your Dagster+ deployment to sync run history, backfills, and your asset catalog into the PostHog Data warehouse.
Create a user token under Organization settings → Tokens in Dagster+, then enter your organization name, deployment name, and the token below.
Configuration
| Option | Type | Required |
|---|---|---|
Organization | text | Yes |
Deployment | text | Yes |
API token | password | Yes |
Linking Dagster+ (Dagster Cloud) to PostHog
- Go to the Data pipeline page in PostHog
- Click New source and select Dagster+ (Dagster Cloud)
- Fill in the required configuration fields
- Click Next, select the tables you want to sync, and then press Import
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
runs | Historical job/pipeline run records for the deployment, used to compute reliability, DORA, and SLA metrics. | Incremental, Full refresh | updateTime, creationTime | — |
backfills | Partition backfills launched in the deployment, including asset backfills. | Full refresh | — | — |
assets | Catalog of assets known to the deployment. | Full refresh | — | — |
schedules | Schedule definitions in each code location, with their cron expression and default status. | Full refresh | — | — |
sensors | Sensor definitions in each code location, with their type, tick interval, and default status. | Full refresh | — | — |
instigation_states | Live state of every schedule and sensor, including the cursor a sensor last stored. | Full refresh | — | — |
instigation_ticks | Tick history for every schedule and sensor — one row per evaluation, with its outcome and the runs it requested. Used for orchestration reliability analysis. | Incremental, Full refresh | timestamp | — |
asset_nodes | Asset definition metadata — group, owning jobs, dependencies, partitioning, and freshness policy. Resolves the bare asset keys in the assets table. | Full refresh | — | — |
asset_materializations | Materialization event history per asset — one row each time an asset was materialized, with the metadata the run attached. The fact table behind the asset catalog. | Incremental, Full refresh | timestamp | — |
asset_observations | Observation event history per asset — one row each time an observable asset was observed, with the metadata the observation reported. | Incremental, Full refresh | timestamp | — |