dagster-slack

dagster-slack is the official Slack integration library maintained inside the Dagster monorepo. It wraps the slack_sdk WebClient in a Dagster-native ConfigurableResource so any op, asset, schedule, or sensor can post to Slack using a single injected token, instead of every call site instantiating its own client.

Beyond the base resource, the package ships two higher-level building blocks aimed squarely at pipeline observability: slack_on_success/slack_on_failure hooks that attach directly to ops and jobs to message a channel on step completion, and make_slack_on_run_failure_sensor, a factory that wires a run-failure sensor across one job, several jobs, or an entire code location and posts formatted Slack blocks (with a deep link back into the Dagster UI) when a run fails.

Because it lives under python_modules/libraries/ in the dagster-io/dagster monorepo and is versioned in lockstep with core dagster on every release, it stays compatible with the exact platform version it ships alongside rather than trailing behind as a separately-released integration.

What You Get

• SlackResource, a ConfigurableResource wrapping slack_sdk.WebClient so any op, asset, schedule, or sensor can call chat_postMessage through one configured token
• A legacy slack_resource function-based resource for codebases still on the pre-Pythonic-resources API
• slack_on_success and slack_on_failure hook factories that attach to ops or entire jobs and post a formatted message (with optional Dagster UI deep link) on step completion
• make_slack_on_run_failure_sensor, a sensor factory that can monitor a specific set of jobs, every job in a code location, or every job across repositories, and posts rich Slack block messages instead of plain text
• Customizable message and block builders (text_fn, blocks_fn, message_fn) so notification content can be tailored per team without forking the integration

Common Use Cases

• Posting a Slack alert to an on-call channel whenever a critical ETL job fails, with a one-click link back to the failed run in the Dagster UI
• Notifying a data team channel on successful completion of a nightly batch job so downstream consumers know new data has landed
• Standing up a single run-failure sensor that watches every job in a code location and routes failures to a shared incident channel
• Sending ad-hoc status messages from inside custom ops or assets using the injected SlackResource for pipeline-specific notifications beyond simple success/failure

Under The Hood

Architecture dagster-slack is a thin, resource-oriented adapter rather than a standalone application: resources.py defines SlackResource (a Pydantic-backed ConfigurableResource) whose only job is to construct and hand back a slack_sdk.web.client.WebClient, plus a @dagster_maintained_resource-decorated legacy slack_resource function for the older function-based resource API. hooks.py and sensors.py build directly on top of that resource: slack_on_success/slack_on_failure wrap Dagster’s success_hook/failure_hook decorators and pull context.resources.slack at execution time, while make_slack_on_run_failure_sensor composes a run_failure_sensor and constructs its own WebClient from a passed-in token rather than depending on the resource system, so it can be attached at the repository level independent of any single job’s resource configuration. The whole package intentionally has almost no branching logic of its own — it reduces to three integration points (resource, hooks, sensor factory) that all funnel into slack_sdk’s chat_postMessage call, keeping the failure surface small.

Tech Stack The package targets Python 3.10–3.15, is built with the hatchling backend, and is managed with uv (dependency locking via uv.lock, environment sync via tox-uv in tox.ini). Its only runtime dependencies are dagster (pinned to the exact in-repo version via [tool.uv.sources] path dependencies, so it always tracks its sibling dagster package) and slack_sdk, Slack’s official Python client. Test dependencies pull in dagster[test], dagster-pipes, and dagster-shared from sibling paths in the same monorepo, reflecting that this is one library among dozens of dagster-* integrations built and released together rather than an independently versioned project.

Code Quality Tests live in dagster_slack_tests/ and cover the resource, hooks, sensors, and version module separately, using unittest.mock.patch on slack_sdk.WebClient.api_call/chat_postMessage to assert calls are made with the right channel and text without hitting the real Slack API — both the modern SlackResource and the legacy slack_resource code paths are exercised. Type hints are used throughout the public API (Callable[[HookContext], str], Sequence[Union[...]] selectors), and deprecated parameters (dagit_base_url) are handled explicitly via @deprecated_param decorators with normalize_renamed_param, rather than silently accepting stale kwargs. As part of the larger dagster-io/dagster monorepo, it inherits that project’s shared CI, linting, and release pipeline rather than defining its own.

What Makes It Unique The package’s value isn’t a novel Slack client — slack_sdk already does that — but the depth of its integration into Dagster’s execution and observability model: hooks fire from within the same execution context as the op/job they’re attached to, and the run-failure sensor can be scoped to one job, a list of jobs, or an entire deployment without extra orchestration code. The deep-link-back-into-Dagster-UI behavior on failure messages is a small but deliberate design choice that turns a generic Slack ping into an actionable alert for whoever’s on call.