# laravel/slack-notification-channel moves the Slack transport out of the framework > The Laravel Slack Notification Channel is a small MIT licensed package that lets a Laravel application deliver its notifications to Slack, and it is deliberately thin. The README is a pointer to the framework documentation, the code lives in a src/ directory with a test suite, and the repository tracks a 3.x branch in step with the major version of the framework's notification system. **laravel/slack-notification-channel** — Slack Notification Channel for laravel. - Repository: https://github.com/laravel/slack-notification-channel - Website: https://laravel.com/docs/notifications#slack-notifications - Stars: 891 · Forks: 70 - Language: PHP - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/laravel-slack-notification-channel ## A package whose README mostly points elsewhere The first thing to understand about this repository is that it is deliberately not where the documentation lives. The README has a single content section beyond the badges, and it points at the official documentation on the Laravel website, at the notifications page and specifically the Slack notifications anchor. There is no usage example, no configuration snippet, no list of environment variables and no code sample anywhere in the file. The rest of the README is the standard Laravel package boilerplate: a Contributing section pointing at the contribution guide in the Laravel documentation, a Code of Conduct section pointing at the Laravel code of conduct, a Security Vulnerabilities section pointing at the repository's own security policy, and a License section stating that the package is open source software licensed under the MIT license. That is a deliberate division of labour, and it works because the package is not a standalone application. It is a channel implementation inside Laravel's notification system, so the way you configure it, the way you route a notification to it and the way you set the credentials are all questions that belong to the framework's documentation rather than to the transport package. For an engineer evaluating the project, the consequence is that the README tells you very little and the documentation tells you nearly everything. That is a reasonable trade for a package this small, and it also means you cannot judge the package's behaviour from the repository alone. What you can judge is the packaging, the version line and the quality tooling, which is what the rest of this article is about. ## The version line is the framework's version line The default branch is 3.x, and the recent releases are v3.10.0 on 2026-08-04, v3.9.0 on 2026-07-21 and v3.8.0 on 2026-03-17. The last push to the repository was on 2026-10-16. Two things follow from that naming. First, the major version of the package is not independent. A 3.x channel belongs to a 3.x notification system, and the repository has an UPGRADE.md file at the root, which is the document you read when the framework moves to a new major version and this package has to move with it. Second, the release cadence is tied to framework releases rather than to feature work in the transport. Three releases in the space of about five months, with patch numbers climbing inside a single major, is the shape of a package that is being kept in step with something larger. There is nothing here about Slack specific features landing in the channel, and the CHANGELOG.md is where you would look to see what actually changed between v3.9.0 and v3.10.0. The distribution route is Packagist. The badges in the README point at the package page on packagist.org, for the total downloads, the latest stable version and the licence, and the package name is laravel/slack-notification-channel, which is what you would put in a composer.json require block. For a team, the practical consequence is the usual one for a Laravel package. You do not adopt this independently, you adopt it inside an application that is already on a Laravel version, and you take the version that matches. Pinning it in a composer.json and letting the framework's own constraints do the work is the sane approach, because the alternative is a channel that is one major version behind the notification API it plugs into. ## Static analysis, a test suite and StyleCI in the root The repository listing is short, and three of the files in it say more about the project's engineering standards than the README does. There is a phpstan.neon.dist file, which is the configuration for PHPStan, the static analyser. A package that ships a static analysis configuration is one where the analyser runs in continuous integration and its findings are part of the definition of done. There is a phpunit.xml.dist file, the standard PHPUnit configuration, and a tests/ directory next to it, so the package has a test suite rather than relying on the framework's own tests to cover it. There is a .styleci.yml file, which is the StyleCI configuration, and that is how the Laravel ecosystem handles code style: a hosted service checks the diff and applies the preset, rather than every contributor formatting by hand. Alongside it is an .editorconfig, which covers the whitespace and line ending conventions that an editor applies before StyleCI ever sees the file. The build status badge points at a GitHub Actions workflow called tests, so the tests, the analyser and the style check all run on the same push. None of this is exotic, and that is the point. For a package whose job is to be a dependable adapter between two systems, the value is in the boring guarantees: the code is analysed, the behaviour is tested, and the style is uniform. An engineer reading this repository cannot see the Slack behaviour, because the behaviour is in the documentation, but they can see that the implementation is held to a standard. ## What the repository does not tell you about Slack It is worth being explicit about the gaps, because a channel that sends to Slack has to answer some hard questions and none of them are answered here. The README does not say how the channel authenticates. Whether it posts through an incoming webhook or through a bot token is not stated anywhere in this repository, and neither is the name of the configuration key or the environment variable that would hold it. It does not say which Slack API the message is posted to, how the framework's notification payload is mapped onto a Slack message, or what happens to a notification that Slack rejects. It also does not say anything about the Slack side of the setup. A working integration needs a Slack app or a bot with a token and a set of scopes, and none of that is described here, because it is described in the documentation the README points to. That silence is not a defect on its own. The documentation link is the project telling you where the answer is, and the package is small enough that the framework docs can stay authoritative across every version of the package. But it does mean that an evaluation of this repository alone will tell you about the packaging and not about the behaviour, and that a team adopting it should read the Slack notifications section of the Laravel documentation before writing any code. The UPGRADE.md file is the other place to look, because in a package that follows a 3.x line, the upgrade notes are where behaviour changes are recorded for each major version. ## Why the transport lives outside the framework The design choice visible in the repository is that Slack is not part of Laravel itself, and the package name makes the shape of the ecosystem explicit. Laravel's notification system is designed so that a notification class describes what to send and a channel class decides where it goes. A channel for Slack is exactly the kind of thing that benefits from being a separate package: the framework does not need to depend on a Slack client, an application that never sends to Slack does not install one, and the Slack client can be upgraded on its own cadence rather than waiting for a framework release. The sibling entries in the same namespace, the other notification channel packages for the various providers, follow the same pattern, and that is what makes the approach coherent rather than a one off. A framework release then ships the notification system, and the channels fill in behind it. The consequence for a developer is that the channel is selected the same way any other channel is, through the notification's route or its channel method, and the Slack specific configuration is read by the channel at send time. The README does not spell that out either, and the framework documentation is again where to look. The MIT licence is the other thing that makes this arrangement workable. A permissive licence means a channel can be forked, vendored or replaced without a licensing conversation, which matters for the segment of the ecosystem that is not willing to take a dependency on a hosted service at all. ## A small repository with an institutional maintenance story The repository itself is minimal by design. There is a src/ directory for the implementation, a tests/ directory for the test suite, a composer.json for the package definition, and the standard set of project files: .editorconfig, .gitattributes, .github/ for the workflows, .gitignore, .styleci.yml, a CHANGELOG.md, an UPGRADE.md, a LICENSE.md and a README.md. There is no documentation directory, no config directory, no service provider discovery file beyond what the framework provides, and no docker or CI configuration beyond the GitHub Actions workflow the badge points to. The whole thing is a channel implementation and its tests. The maintenance story, though, is institutional rather than personal. The contributing guide, the code of conduct, the security policy and the official documentation all live in the Laravel project's own repositories and website, which means the rules a contributor follows are the framework's rules, and a security report goes to the process the framework has already established. That structure has an obvious upside and an obvious limit. The upside is consistency: the package behaves like every other part of the Laravel ecosystem, the documentation is maintained alongside the framework, and the version line tells you which Laravel you are on. The limit is that the package carries no independent capability of its own, so there is little here to adopt on its own terms. It is infrastructure, which is exactly what it should be and exactly what it is. ## Conclusion Adopt laravel/slack-notification-channel if your Laravel application already sends notifications through the framework's notification system and you want a Slack target without hand rolling a webhook call inside a listener. Do not adopt it if you need a richly formatted Slack message builder, a rich block kit composer or connection management, because none of that is described in this repository. Before you wire it up, read the Slack notifications section of the Laravel documentation, since the README carries no configuration keys, no webhook or token setting and no mention of the Slack app or bot permissions the channel needs, and check the UPGRADE.md file in the repository before moving between major versions of the 3.x line. ## FAQ ### What does the laravel/slack-notification-channel package do? It is the Slack channel implementation for the Laravel notification system, so a Laravel application can deliver its notifications to Slack. The package is distributed on Packagist as laravel/slack-notification-channel and the current release is v3.10.0 from 2026-08-04. ### Where is the documentation for the Laravel Slack notification channel? In the official Laravel documentation, on the notifications page at the Slack notifications section, which the README links to. The repository itself contains no usage example, configuration snippet or environment variable list. ### How do I install the Laravel Slack notification channel? It is a Composer package published on Packagist under the name laravel/slack-notification-channel, and the README badges point at that package page for the download count, the latest stable version and the licence. The configuration of the channel itself, including the credentials, is documented by Laravel. ### What quality checks does the repository run? The root holds a phpstan.neon.dist configuration for static analysis, a phpunit.xml.dist with a tests/ directory, and a .styleci.yml for code style, with an .editorconfig for editor conventions. A GitHub Actions workflow called tests carries the build status badge. ### Which versions of the Laravel Slack notification channel are released? The recent releases are v3.10.0 on 2026-08-04, v3.9.0 on 2026-07-21 and v3.8.0 on 2026-03-17, on a 3.x default branch that tracks the major version of the framework's notification system. UPGRADE.md in the repository root holds the upgrade notes. ## Sources - [laravel/slack-notification-channel on GitHub](https://github.com/laravel/slack-notification-channel) - [License: MIT](https://github.com/laravel/slack-notification-channel/blob/3.x/LICENSE) - [Project website](https://laravel.com/docs/notifications#slack-notifications) - [README](https://github.com/laravel/slack-notification-channel/blob/3.x/README.md) - [Releases](https://github.com/laravel/slack-notification-channel/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/laravel-slack-notification-channel