Backup Monitor Laravel Package

Technical Evaluation

Architecture fit. This is an observability/ops surface, not a domain component: a read-only admin (CP) page that reports whether each configured backup disk is being monitored, layered on top of spatie/laravel-backup. It does not appear to own schema, queues, or request-path logic, so architectural intrusion is minimal. It fits as a satellite operational tool alongside Horizon/Telescope-class packages, not as something the core application depends on. The v1.1.0 addition — explaining why a disk is "Not monitored" — reinforces that framing: the package's job is diagnosis and visibility, not backup execution or alerting.

Integration feasibility. High. Assumed footprint: composer require → vendor:publish for config and CP assets → populate a monitor_backups array with disk names that must match config/backup.php keys. Effort is hours for a Laravel-fluent engineer, not weeks. The gating precondition is that spatie/laravel-backup is already installed, scheduled, and writing successfully — this package surfaces that state, it does not create it.

Technical risk. Low, with three caveats worth logging:

1. Silent misconfiguration is the dominant risk, and v1.1.0 only partially mitigates it. The release note explicitly calls out case-mismatched disk names as a cause of "Not monitored." That confirms matching is string-based and case-sensitive, and that a typo produces a plausible-looking UI state rather than a validation error. v1.1.0 improves explainability after the fact; it does not appear to validate monitor_backups against backup.disks at boot or via an artisan command. That is the single highest-value follow-up to request.
2. Asset publishing uses --force. Documented as a required post-upgrade step for CP assets. Safe for package-owned files; a hazard only if we ever patch those assets locally, which we should explicitly forbid.
3. Scope boundary vs. expectation. The README addition points users to spatie's MaximumAgeInDays / backup:monitor for staleness alerting. Read correctly: this package does not alert on stale backups. A stakeholder who sees a green "monitored" page may assume alerting is covered. Expectation management is a real TPM task here.

Key questions.

• Which versions of Laravel, PHP, and spatie/laravel-backup are supported? (Not stated in the release notes.)
• Is the CP a Statamic Control Panel, Filament, or Nova surface — and what is the authorization model for viewing backup status?
• Does the page enumerate remote disk contents (e.g. S3 listObjects) per render, or read cached/scheduled results? This determines latency and IAM requirements.
• Does a "Not monitored" state surface anywhere machine-readable — a health endpoint, exit code, or JSON — or is it UI-only?
• Is there a validation command or boot-time check for monitor_backups?
• Does --force re-publish overwrite only compiled assets, or config as well?

Integration Approach

Stack fit. Laravel + spatie/laravel-backup + a PHP 8.x runtime; additive composer dependency with no infrastructure requirements (no Redis, no new DB tables assumed). Fits any environment where the backup package is already the standard.

Migration path. Greenfield addition. No data migration, no schema change. For an existing install, v1.1.0 is a drop-in minor bump; the only required action is re-running php artisan vendor:publish --tag=backup-monitor --force so the CP bundle reflects the new diagnostics.

Compatibility. Additive release: new UI explanatory text plus documentation. No deprecations, no breaking changes, no config key renames. The patch-level content under a minor version bump is consistent with semver.

Sequencing.

1. Confirm spatie/laravel-backup is configured, scheduled, and producing backups to real disks.
2. Install the package in staging; publish config and CP assets.
3. Populate monitor_backups by copying disk keys verbatim from config/backup.php — do not retype them.
4. Verify the CP page shows "Monitored" for each intended disk; deliberately test one case-mismatched entry to confirm the new v1.1.0 explanation renders.
5. Establish actual paging separately: schedule backup:monitor with MaximumAgeInDays (or the documented hours-based custom check) and route failures to the on-call channel.
6. Promote to production outside a backup window; re-publish assets as part of the deploy step, not manually.

Operational Impact

Maintenance. Low. One config file, no database, no migrations, no long-running processes. The recurring chore is keeping monitor_backups in sync when disks are added to or removed from backup.php — this is the drift vector and the thing most likely to generate a false alarm or a false all-clear.

Support. v1.1.0 is a net support-cost reduction: "Not monitored" now self-explains into three known causes (empty monitor_backups, disk absent from it, case mismatch), which removes the most common L1 escalation. The README's alerting section also gives support a documented answer to "why didn't we get paged?" — the answer being that paging comes from backup:monitor, not from this page.

Scaling. Negligible compute footprint. The only scaling consideration is page render latency if it queries remote disk listings synchronously across many disks or tenants; confirm caching behaviour before rolling out broadly.

Failure modes to document.

• Case-mismatched disk name → silent "Not monitored" with no boot-time error (now diagnosable, still not prevented).
• Empty or stale monitor_backups after a backup config refactor.
• Stale compiled CP assets after upgrade, showing pre-v1.1.0 messaging.
• --force publishing overwriting any locally modified assets.
• Stakeholder assumption that a green page means alerting is configured — the most likely organizational failure, and the one worth pre-empting in the rollout note.

Ramp-up. Under an hour for a Laravel-fluent engineer; config-driven, no new mental model. The only concept to teach is the relationship between backup.php disk keys and monitor_backups, plus the explicit handoff to backup:monitor for staleness alerting.