List recent pipeline runs. Start here to discover what has been running.

Returns runId, status, jobName, startTime, endTime, and tags for each run. Use the returned runId to drill into details with get_run_status, get_run_logs, get_run_stats, or get_run_failure_summary.

Filtering:

• job_name: filter by job (e.g. 'my_etl_job')

• statuses: filter by one or more statuses. Valid values: 'SUCCESS', 'FAILURE', 'CANCELED', 'STARTED', 'QUEUED', 'STARTING', 'CANCELING', 'NOT_STARTED'. Examples: ['FAILURE'], ['FAILURE', 'CANCELED'], ['STARTED', 'QUEUED']

• limit: max runs to return (default 10)

Typical workflows:

• Find recent failures: get_runs(statuses=['FAILURE'])

• Check if a job ran today: get_runs(job_name='my_job', limit=5)

• Monitor active runs: get_runs(statuses=['STARTED', 'QUEUED'])

Get full details for a single run: status, config, tags, and run lineage.

Returns: runId, status, startTime, endTime, jobName, tags, runConfigYaml, rootRunId, parentRunId, resolvedOpSelection.

Use rootRunId and parentRunId to understand re-execution chains — if parentRunId is set, this run was re-executed from another run. resolvedOpSelection shows which steps were selected for re-execution.

When to use: after get_runs to inspect a specific run, or to check whether a run is a re-execution of a previous one.

Get structured log events for a run, with optional severity filtering and pagination.

Returns events with __typename, timestamp, message, level, and (where applicable) stepKey and error details. Events include step starts/completions, failures, retries, materializations, and run-level events. EngineEvent events also carry metadataEntries — a list of {label, description, value} dicts (e.g. run worker image, k8s pod name, step keys) surfaced by the engine.

Parameters:

• run_id: the run to fetch logs for

• level_filter: only return events at this level or above. Values: 'DEBUG', 'INFO', 'WARNING', 'ERROR'. When set to 'ERROR', also includes ExecutionStepFailureEvent and RunFailureEvent regardless of their level field. Default: None (return all events).

• cursor: pagination cursor returned in previous response. Pass the cursor from the last call to get the next page.

• limit: max events per page (default 100)

When to use: to investigate what happened during a run. For a quick failure diagnosis, prefer get_run_failure_summary instead — it returns a consolidated view in a single call. Use get_run_logs when you need the full event stream or want to filter by level.

Get per-step execution statistics for a run: timing, materializations, and expectations.

Returns runId, status, and a stepStats array where each entry has: stepKey, status, startTime, endTime, materializations (with labels), and expectationResults (with success flag and labels).

When to use: to find slow steps (compare startTime/endTime), check which steps materialized assets, or verify expectation results. For failed runs, prefer get_run_failure_summary which includes step stats alongside error details and suggestions.

Get a consolidated failure diagnosis for a run in a single call.

This is the BEST tool to use when investigating a failed or canceled run. It combines status, step stats, and error logs into one response, avoiding the need to call get_run_status + get_run_logs + get_run_stats separately.

Returns:

• status, job_name, duration_seconds

• failed_steps: list of {step_key, duration, error} for each failed step

• root_cause_error: the RunFailureEvent error (if any)

• all_step_durations: timing for every step (not just failed ones)

• suggestions: automated diagnostic hints (e.g. 'Multiple steps failed', 'Step was retried before failing', 'Run was canceled')

If the run did not fail, returns {message: 'Run did not fail.'}.

When to use: always prefer this over get_run_logs for failed runs. Use get_run_logs only when you need the full event stream.

Get the most recent materializations for an asset, with metadata.

Returns a list of materializations, each with: runId, timestamp, assetKey, and metadataEntries (labels, numeric values, text).

• asset_key: the asset name as a string (e.g. 'my_daily_report')

• limit: max materializations to return (default 5)

When to use: to check when an asset was last materialized, track materialization frequency, or inspect metadata from recent runs. For a broader health view (including staleness and freshness), use get_asset_health instead.

Get detailed metadata for one or more assets: description, lineage, and partitions.

• asset_keys: list of asset name strings (e.g. ['my_extract', 'my_load'])

Returns per asset: assetKey, description, groupName, op name, isObservable, isPartitioned, partitionDefinition, dependencyKeys (upstream assets), dependedByKeys (downstream assets), and the latest materialization (runId + timestamp).

When to use: to understand an asset's lineage (what it depends on and what depends on it), check if it's partitioned, or get its description. Use search_assets first if you don't know the exact key.

Search and list assets by name prefix or group. Use this to discover assets.

Returns per asset: assetKey, groupName, description, isPartitioned, op name.

• prefix: case-insensitive substring match on any part of the asset key (e.g. 'raw_' finds 'raw_orders', 'raw_users')

• group: exact match on groupName (case-insensitive, e.g. 'analytics')

• Both filters can be combined.

• If neither is passed, returns ALL assets.

When to use: to discover available assets before calling get_asset_details or get_asset_health. Use prefix for fuzzy search, group for scoped listing.

Resolve Dagster asset-selection syntax into concrete assets without launching a run.

Supported syntax:

• key predicates (key:orders or bare orders) with * wildcards

• group:, tag:, kind:, and owner: predicates

• case-insensitive and, or, and not with parentheses

• roots(...) and sinks(...)

• upstream/downstream traversal such as +orders, 2+orders, orders+, orders+2, or 1+orders+2

Returns asset_keys as slash-delimited strings ready to pass to materialize_assets or backfill_assets, plus compact GraphQL-shaped asset summaries. This tool is read-only and does not filter external, observable, non-executable, or partitioned matches.

Get a consolidated health view for a single asset or all assets in a group.

This is the BEST tool to assess whether assets are healthy and up-to-date.

• asset_key_or_group: pass either a single asset key (e.g. 'my_report') or a group name (e.g. 'analytics'). If it matches a group, returns health for ALL assets in that group.

Returns per asset:

• asset_key, group, description

• last_materialization: {run_id, timestamp, status} of the latest run

• freshness_policy: {maximum_lag_minutes, cron_schedule} if defined

• staleness: {is_stale, reasons[]} explaining why the asset is stale

When to use: to check if critical assets are fresh, find stale assets in a group, or verify that recent materializations succeeded. Prefer this over get_recent_materializations when you need a health assessment rather than raw materialization history.

List all jobs across all code locations. Use this to discover available jobs.

Returns per job: repository name, code location name, job name, and description.

When to use: as a starting point to explore what jobs exist, or to find the exact job name and repository_location needed for launch_job.

List all schedules with their status, cron expression, target job, and next tick.

Returns per schedule: name, cron expression, status (RUNNING/STOPPED), next_tick timestamp, target job name, repository, and code location.

When to use: to check which schedules are active, verify cron timing, or find schedules that are stopped and might need attention. If a schedule is RUNNING but jobs aren't executing, use get_tick_history to inspect recent ticks for errors.

List all sensors with their status and target jobs.

Returns per sensor: name, status (RUNNING/STOPPED), list of target job names, repository, and code location.

When to use: to check which sensors are active and what jobs they trigger. If a sensor is RUNNING but not producing runs, use get_tick_history to inspect recent ticks — it will show skipped ticks, errors, or runs launched.

Get recent tick history for a schedule or sensor — essential for detecting silent failures.

• instigator_name: exact name of the schedule or sensor (from list_schedules/list_sensors)

• instigator_type: 'SCHEDULE' or 'SENSOR'

• limit: max ticks to return (default 20)

• repository_name / location_name: optional, to disambiguate when the same name exists in several code locations (see list_schedules/list_sensors)

Returns per tick: tick_id, status (SUCCESS/FAILURE/SKIPPED), timestamp, error message (if failed), and run_ids (runs launched by this tick).

When to use: when a schedule or sensor is RUNNING but data is not being produced. Common patterns to look for:

• All ticks SKIPPED: sensor condition not met, or misconfigured

• Ticks with FAILURE status: the schedule/sensor code is erroring

• Ticks with SUCCESS but empty run_ids: sensor evaluated but decided not to launch

• Missing ticks: daemon may be unhealthy (check get_instance_status)

List all code locations and their load status.

Returns per location: name, loadStatus (LOADED/LOADING), and either the repositories within it or a PythonError if loading failed.

When to use: after a deployment to verify code locations loaded correctly, or when get_instance_status reports code location errors. If a location failed to load, use reload_code_location to retry.

Get a global health check of the Dagster instance. START HERE for any monitoring workflow.

Returns:

• healthy: boolean — true only if all required daemons are healthy AND no code locations have errors

• daemons: list of {type, healthy, last_heartbeat, required} for each daemon (scheduler, sensor, run coordinator, etc.)

• queued_runs_count: number of runs waiting in queue (high count = bottleneck)

• code_location_errors: list of {name, error} for locations that failed to load

When to use: as the FIRST call in any diagnostic or monitoring flow. If healthy=false, check daemons for unhealthy entries and code_location_errors for loading failures. Follow up with list_code_locations or get_runs as needed.

List recent asset backfills with their status and partition progress.

Returns per backfill: backfillId, status, numPartitions, timestamp, partitionNames, and partitionSetName.

• limit: max backfills to return (default 10)

When to use: to monitor in-progress backfills or review recent ones.