okipa/laravel-supervisor-downtime-notifier
Monitors Supervisor-managed processes in your Laravel app and alerts you the moment they go down. Catch stopped queue workers and failed daemons early with configurable downtime notifications, so you can react before jobs pile up and users notice.
Version 2.4.0 is a compatibility-only release: the API surface hasn't changed, but the support matrix has moved. Before anything else, confirm your app sits inside it:
composer.json pins php to ~8.1.0 || ~8.2.0 (or equivalent), not >=8.1.^2.4.php -v
composer show laravel/framework | grep versions
composer require <vendor>/<package>:"^2.4" --dry-run
The --dry-run is the fastest signal — if it resolves cleanly you're compatible; if not, the error names the conflicting constraint directly.
Where to look first: the package's service provider and config/<package>.php. Nothing in 2.4.0 changes them, which is itself useful information — any config you had published under 2.3.x remains valid, so you do not need to re-publish and diff.
First use case: pick the single code path where you already depend on the package (a job, a controller action, a test) and run it against 2.4.0 on Laravel 10 / PHP 8.1. Because this release is version-support only, a green run there is strong evidence the whole upgrade is safe.
Upgrade path from 2.3.x. Treat this as two independent upgrades and do them in order:
^2.3.^2.4 in a separate commit.Doing both at once makes a failure ambiguous — you won't know whether Laravel 10 or the package bump broke the test. The two-commit approach also means the package bump diff is a single line in composer.json plus composer.lock, which is trivial to revert.
Pin the constraint deliberately. Use "^2.4" rather than "*" or a branch alias. Because 2.4.0 is the first release that excludes Laravel 8, an unpinned constraint lets composer update silently downgrade a Laravel 8 app back to 2.3.x — an upgrade that never happens and is easy to miss in review.
CI matrix. If the package is part of a shared internal library or you test it directly, run a matrix of php: [8.1, 8.2] × laravel: [9.*, 10.*]. Anything testing 8.0 or 8.3 will now fail at the install step rather than the test step, which is a confusing failure mode if you don't expect it.
Lockfile hygiene in a monorepo. If several applications consume this package, bump them one at a time and run each suite. The version-support change is global but the risk is not — one app might be exercising a code path that a PHP 8.2 deprecation warning turns into a hard failure under a strict error handler.
Integration tip — use the composer.json as the source of truth. Rather than trusting release notes, read the constraints straight out of the installed package:
composer show <vendor>/<package> --all | grep -A5 requires
That gives you the exact php and illuminate/* ranges the maintainer actually shipped, which is more precise than a changelog bullet.
PHP 8.3 is not "probably fine." The lock to 8.1/8.2 is a hard composer constraint, so on a machine running 8.3 composer install fails outright rather than producing deprecation notices. If your local box or CI image has drifted to 8.3, you'll see a resolve error before you see a single test run. Fix the environment, don't reach for --ignore-platform-reqs — that flag bypasses the check without making the code actually run on 8.3.
Laravel 8 apps are frozen on 2.3.x. They will keep working, but security and bug fixes stop there. If you're maintaining a Laravel 8 application that depends on this, the honest options are: upgrade the app, or fork and widen the constraints yourself and accept the maintenance. Don't assume a 2.4.x patch will be backported for Laravel 8.
"Dropped Laravel 8 support" is not always a semver-major. Many maintainers ship this as a minor bump because the dropped support is a constraint change rather than an API change. That means composer update can move you from 2.3 to 2.4 without you consciously opting in — but only if your app is already on Laravel 9/10, in which case the change is a no-op. The risk is inverted from what you'd expect: the people who get bitten are the ones who can't install it, not the ones who do.
Debugging a failed resolve. The error message is usually long and nests the real cause. Reduce it:
composer why-not <vendor>/<package> 2.4.0
That names the package (often laravel/framework) and the constraint blocking the install, which is far quicker than reading the full solver output.
No config or migration work needed. If you were bracing for a re-publish of the config file or a new migration after bumping to 2.4.0, don't — none is implied by these notes. Resist the habit of running vendor:publish --force on every upgrade; it will overwrite local customisations for zero benefit here.
Extension points are unchanged, so custom bindings survive. Any container bindings, macros, or subclass overrides you registered against the package's contracts under 2.3.x continue to work. This is the main reason the upgrade is low-risk despite being a version-support release.
Watch for the next release, not this one. A changelog that is purely a support-matrix shift usually signals the maintainer clearing the decks for a feature release. Pin with ^2.4 rather than >=2.4 so the next minor doesn't land in production unreviewed.
How can I help you explore Laravel packages today?