Dagster

Integrate Dagster data orchestration into your workflows. Launch job runs, poll status, fetch execution logs, inspect schedules, and terminate in-progress runs — all from within a Zelaxy workflow.

Overview

Operations

Configuration

Outputs

Launch Run

Get Run

Get Run Logs

List Runs

Terminate Run

List Jobs

List Schedules

Example

[Starter] → [Dagster: Launch Run] → [Dagster: Get Run] → [Agent: summarize result]

Connect a Starter block that fires on a webhook or schedule, then pass {{DAGSTER_API_KEY}} as the API key and your instance URL (e.g. {{DAGSTER_HOST}}) as the host. The Launch Run block triggers {{starter.jobName}} in repository location my_repo_location; downstream blocks can poll status using {{dagster_launch_run.runId}} in a Get Run block, and an Agent block can turn the final status and runConfigYaml into a human-readable summary.

Tips

• OSS vs Dagster+ — apiKey is optional for self-hosted OSS Dagster instances that have no auth configured. For Dagster+ (cloud), supply your user token or organization token via {{DAGSTER_API_KEY}}.
• Repository selector — repositoryLocationName is the code-location name shown in the Deployments tab of the Dagster UI; repositoryName is almost always __repository__ for single-repo locations. Use the List Jobs operation to discover the correct values programmatically.
• Polling for completion — Dagster runs are asynchronous. After Launch Run, use a loop block calling Get Run with the returned runId until status is SUCCESS or FAILURE. Check startTime and endTime to calculate duration.
• Log pagination — Get Run Logs returns a cursor and hasMore flag. Pass cursor as afterCursor in a subsequent call to retrieve the next page. Limit per page defaults to the Dagster server's maximum if not specified.
• Status filter format — The statuses param for List Runs is a comma-separated string (e.g. SUCCESS,FAILURE), not a JSON array. The tool splits and trims it automatically before sending the GraphQL query.