Installation

Require the package. The service provider and the Health facade alias are auto-discovered — no manual registration:

composer require roundly-consulting/alerts-for-laravel

If the models that will own health checks use UUID or ULID keys, set ALERTS_KEY_TYPE first — the owner columns are typed when the migrations run (see Database schema & key types). Then publish and run the migrations:

php artisan vendor:publish --tag="alerts-migrations"
php artisan migrate

Publish-only migrations

The package never registers its migrations with the migrator, so php artisan migrate runs exactly the six files you published, in the order they were published: health_checks first, then alerts, alert_silences and health_check_runs, then the two additive 1.2 migrations that add identity_hash to health_checks and alert_silences. Publishing again is idempotent — it overwrites in place rather than dropping a second copy.

Upgrading to 1.2

1.2 adds two forward-only migrations. add_identity_hash_to_health_checks_table adds a nullable, unique health_checks.identity_hash, with no backfill. add_identity_hash_to_alert_silences_table adds a nullable, unique alert_silences.identity_hash; it first collapses the immediate silences already stacked per key and scope into one — the newest row, open-ended if any of them was, otherwise until the latest end, with the newest reason — so what is muted does not change. Publish and migrate again:

php artisan vendor:publish --tag="alerts-migrations"
php artisan migrate

If you edited a published alerts migration, vendor:publish no longer recognises it and would publish a second copy of the create migrations — copy the two new files into database/migrations by hand instead. On MySQL, 1.2 needs MySQL 8.0 or later.

• Health::report() now reads muted from the silences in force and reports uptime and p95LatencyMs as null for a check with no runs, instead of 100.0 and 0 (see Status reports & health endpoint).
• Muting the same key and scope again updates that silence instead of inserting another (see Maintenance windows & muting).
• A check that throws no longer stores or mails its exception’s message and stack frames — they go to your exception handler (see Timeouts & error handling).

Optional: config and translations

php artisan vendor:publish --tag="alerts-config"
php artisan vendor:publish --tag="alerts-translations"

The config is merged from the package, so the env-backed keys work without publishing. The check messages and the default failure notification ship in English and Slovak, and Laravel picks the lines for the app locale — publish the translations (to lang/vendor/alerts) only to reword a line or add another language.

Quick start

Register a check, attach it to an owner model, and let the scheduler do the rest:

// app/Providers/AppServiceProvider.php — boot()
use RoundlyConsulting\Alerts\Checks\DatabaseCheck;
use RoundlyConsulting\Alerts\Facades\Health;

Health::check(DatabaseCheck::make('mysql'));

// Anywhere — attach the check to an owner model (see Owner models)
Health::for($team)->monitor(DatabaseCheck::class)
    ->everyFiveMinutes()
    ->throttle(maxAttempts: 1, decayMinutes: 60)
    ->save();

The package is built from three pieces:

• Check — a class you write (or a built-in one, or an inline closure) that performs a check and returns a CheckResult.
• HealthCheck — the database row that schedules a Check at a cron frequency for one notifiable owner.
• Alert — the row created when a health check fails, with triggered_at, recovered_at and the result’s message and meta.

One Artisan command, auto-registered on the scheduler to run every minute, dispatches a queued job for every health check that is due. Make sure Laravel’s scheduler and a queue worker are running (see Running checks).