Inline closure checks

For one-off checks, define one inline instead of writing a class:

use Illuminate\Support\Facades\Redis;
use RoundlyConsulting\Alerts\CheckResult;
use RoundlyConsulting\Alerts\Facades\Health;

Health::define('redis-up', fn () => Redis::ping() ? CheckResult::ok() : CheckResult::failed('Redis down'))
    ->name('Redis')
    ->throttle(maxAttempts: 1, decayMinutes: 15)
    ->notifyUsing(RedisDownNotification::class);

A closure may return a CheckResult or a plain bool — true is ok, false is failed. It receives the ClosureCheck, so it can read the scheduled row’s meta like a class-based check. A notification closure receives the check and the recipient:

use RoundlyConsulting\Alerts\Checks\ClosureCheck;

// The closure receives the ClosureCheck; return a CheckResult or a plain bool.
Health::define('orders-flowing', function (ClosureCheck $check): bool {
    $minutes = $check->healthCheck?->meta['window'] ?? 60;

    return Order::where('created_at', '>=', now()->subMinutes($minutes))->exists();
})->name('Orders flowing');

// A notification closure receives the check and the recipient.
Health::define('queue-drained', fn () => Queue::size() < 100)
    ->notifyUsing(fn (ClosureCheck $check, object $notifiable) => new QueueStuckNotification($check->name()));

Builder options

Health::define() returns a PendingCheck:

notifyUsing() with a class name instantiates it with the check as the only constructor argument. If the class or the closure does not produce a Notification, the bundled HealthCheckFailedNotification is used instead.

Scheduling and running

// An inline check has no class — run it by its key. The throttle and
// options declared on define() apply:
Health::for($team)->run('redis-up');

// Monitor it by its key — the builder starts from define()'s options,
// and any builder call overrides them:
Health::for($team)->monitor('redis-up')
    ->everyMinute()
    ->failAfter(2)
    ->save();

An inline check has no class, so you run and monitor it by its key. Health::for($owner)->run('key') uses the throttle and options declared on define(), and Health::for($owner)->monitor('key') starts from them — any builder call overrides them.

Where the options apply

• name(), description(), tags() and notifyUsing() belong to the check itself and apply wherever it runs.
• throttle(), failAfter(), recoverAfter(), timeout(), notifyVia() and escalate() apply to the on-demand row that Health::for($owner)->run() uses when the owner has no schedule for the check. That row mirrors the definition, so a changed define() takes effect on the next run.
• A row you schedule with Health::for($owner)->monitor('key') starts from the same options and keeps what was saved — change them on that builder.
• The renotification throttle is always read from the row’s max_attempts and decay_minutes, which come from define()’s throttle() or the monitor() builder.