Production operations.

Use this checklist before customer health data drives alerts, customer success workflows, or application access decisions.

Schedule changing calculations

Time-window signals change even when no new event arrives. Schedule score recomputation instead of treating a stored score as permanently current:

use Illuminate\Support\Facades\Schedule;

Schedule::command('customer-health:recompute')
    ->hourly()
    ->withoutOverlapping();

Run the scheduler once per minute through the deployment platform. In a database-per-tenant application, execute recomputation inside each tenant context.

Monitor non-zero exits. The command continues after a subject failure, so some scores may update while others remain stale.

Keep queue workers observable

When queued tracking is enabled, no product event is written until a worker handles the job.

Monitor:

• queue depth and oldest-job age;
• failed RecordProductEvent jobs;
• worker restarts after configuration changes; and
• whether tenant context is restored on the worker.

A job retry can append the same raw activity again. Milestone inserts remain unique.

Schedule raw-event pruning

Run Laravel's model pruning command after setting retention_days:

php artisan model:prune \
  --model='ByRcsc\LaravelCustomerHealth\Models\ProductEventRecord'

Keep retention at least as long as every raw-event reporting and score window. Pruning is irreversible from package storage.

Watch state freshness

Current summary rows include computed_at. Alert or exclude rows older than the expected recomputation cadence:

$stale = CustomerHealth::summaries()
    ->where('computed_at', '<', now()->subHours(2))
    ->get();

An old summary can indicate a failed recomputation, an unresolvable subject, a missing tenant run, or an unavailable database connection.

Listen for HealthStateChanged when state transitions should trigger work. The event fires after a score transaction commits and includes the previous nullable state plus the new state.

Protect score concurrency

The package serializes computations for the same subject and score on MySQL and PostgreSQL. MySQL waits up to 10 seconds for its named lock, then throws ScoreComputationLockException.

SQLite does not acquire an application lock. Avoid running overlapping computations for the same identity on SQLite when transition order matters.

withoutOverlapping() reduces scheduler overlap, but controllers or jobs can still call compute() concurrently. Catch and retry lock timeouts through the application's normal job retry policy.

Back up both storage locations

When summaries use a landlord connection, include both the tenant history tables and landlord summary table in backup and restore plans.

After restoring or truncating summaries, run recomputation to recreate current rows. Score history alone is not read automatically to rebuild a summary.

Deployment checklist

• Published migrations exist on every configured connection.
• Event, checklist, and score declarations are in cached configuration.
• Queue workers use the intended connection and queue.
• Score recomputation runs at the intended cadence.
• Raw-event retention covers the longest activity window.
• Failed commands and queue jobs are monitored.
• Landlord and tenant storage are included in backups.
• Erasure workflows pass the correct tenant ID for landlord summaries.

What to read next

• Queueing events for worker and transaction behavior.
• Recomputing scores for filters and partial failures.
• Troubleshooting to match symptoms to configuration and storage checks.