Laravel Uptime Monitor Laravel Package

Technical Evaluation

Architecture fit

• This is not a service — it is a scheduler-driven package that runs inside a Laravel application. The architectural decision is therefore not "adopt a monitor" but "add a background workload to an existing app and make that app's host the vantage point for all monitoring."
• That vantage point is the central risk. If the monitoring host, its cron daemon, or its queue worker fails, alerting fails silently at exactly the moment you need it. Anything Tier 0 must be monitored from infrastructure that does not share a blast radius with the monitored systems.
• The package's design assumptions are good for a small fleet: config-file-driven monitors, Laravel-native notifications (mail/Slack out of the box, custom notification classes for PagerDuty/Opsgenie/Teams), event hooks (MonitorFailed, SslExpiresSoon), pluggable response checkers, and a swappable monitor_model for extending the domain object.
• There is no API and no UI. Monitor CRUD is artisan-driven (sync command since 2.1.0). For a product team this is the largest functional gap: on-call engineers and service owners cannot self-serve, and there is no system of record beyond the database table.

Integration feasibility

• Low mechanical cost in an existing Laravel estate: composer require, publish config and migrations, register the uptime and certificate check commands on the scheduler, configure channels. A competent Laravel pair can reach a working proof-of-concept in under a day.
• The configuration surface is unusually complete for alerting quality: timeout_per_site, retry_connection_after_milliseconds, concurrent_checks, additional_status_codes, additional_headers, request payload support (3.1.0), per-monitor response checkers (3.2.0), and fire_monitor_failed_event_after_consecutive_failures to suppress flap noise.
• If we have no Laravel app with spare capacity, the evaluation should shift to Spatie's standalone uptime-monitor-app repository rather than deploying a new Laravel app purely to host this package.

Technical risk

Key questions

1. Which services are in scope, and which are Tier 0? Anything Tier 0 should not be monitored solely from inside our own estate.
2. Is there a dedicated host with a scheduler we can HA or at minimum external-watch?
3. Does the queue run with retries and a monitored worker, or will we be on the sync driver?
4. What is the system of record for monitors — config file, DB, or an admin UI we build?
5. Are we replacing an existing vendor (UptimeRobot, Better Stack, Datadog Synthetics)? What is the fully-loaded cost comparison once we price the UI build and on-call ownership?
6. Do we need paging with escalation (PagerDuty/Opsgenie) or is Slack notification acceptable? If paging, we own the notification classes.
7. Who prunes check history, and does anyone need it for SLA reporting? If yes, this package is not the reporting layer.

Integration Approach

Stack fit

• Requires an existing Laravel 8/9/10 application (PHP 7.4–8.1 per the 4.x changelogs; verify Laravel 11/12 support on Packagist before committing — the changelog trail stops mid-4.3.x).
• Fits cleanly if the estate is Laravel-centric and there is already a notification stack (mail, Slack webhook, queue). It fits poorly in a polyglot estate where a PHP app would otherwise not exist.

Migration path

1. Stand up a dedicated, low-blast-radius Laravel host. Do not co-locate with a monitored production service.
2. Install, publish config and migrations, and set uptime-monitor config as code in the repo.
3. Wire the scheduler (uptime + certificate check commands) and a supervised queue worker.
4. Configure notification channels; implement custom notification classes for PagerDuty/Opsgenie if paging is required.
5. Seed monitors — use the sync command for bulk import from the incumbent vendor or from a config manifest.
6. Extend monitor_model if monitors need ownership metadata (team, tier, escalation policy, runbook URL). This requires a schema migration.
7. Build a thin admin surface only if self-service is a stated requirement; otherwise document the artisan workflow explicitly.
8. Add a retention/pruning job for check history.
9. Shadow run in parallel with the incumbent for 2–4 weeks; compare alert fidelity, false-positive rate, and mean time to detect.
10. Cut over channel routing; keep the incumbent in a degraded/silent mode for 30 days.

Compatibility

• DB-backed monitors plus a config file means two configuration sources — pick one as authoritative and enforce it, or drift is inevitable.
• Custom UptimeResponseChecker implementations are the extension point for JSON-health-endpoint or body-content validation; the default LookForStringChecker is too coarse for most APIs.
• Response payload support (3.1.0) allows authenticated health endpoints, but credential handling for those payloads needs its own secrets story.
• Event hooks (MonitorFailed, SslExpiresSoon) integrate with existing observability if we forward them to our internal event bus.

Sequencing

• Highest-uncertainty items first: (a) confirm Laravel version support, (b) prove scheduler reliability on the target host, (c) prove notification delivery end-to-end including queue failure. These three gate the decision.
• UI/API work is scope-flexible and should be deferred to post-cutover unless self-service is a hard requirement.
• Do not decommission the incumbent until the shadow run shows equal-or-better detection and a documented rollback path exists.

Operational Impact

Maintenance

• Low code-level maintenance, moderate upgrade-cadence maintenance. This package is version-coupled to Laravel majors; expect to upgrade it in lockstep and to occasionally wait on a community PR after a Laravel major release. Treat it as a blocker in the Laravel upgrade plan.
• Config lives in the repo and is reviewable; monitor definitions should be treated as production configuration with change control.
• Ongoing chores: prune check history, review the resend interval (resend_uptime_check_failed_notification_every_minutes, default 60) for alert fatigue, and periodically audit monitor coverage against the service catalog.

Support

• MIT license, no SLA, no vendor escalation. Spatie's commercial products do not underwrite this package. This is acceptable for internal tooling; it is not acceptable as the sole paging path for revenue-critical systems without a secondary monitor.
• Bus factor is offset by the package's maturity (README, docs, changelog, releases, v4.x history) and the existence of a standalone sibling app, but issue response is best-effort.

Scaling

• Throughput is a function of concurrent_checks (default 10), timeout_per_site (10s), and retries. A 1,000-monitor fleet at a 5-minute cadence is well within a single modest host, but the check cycle must complete inside the interval — model this before promising 1-minute cadence.
• Single scheduler process means no horizontal scale-out without partitioning monitors across hosts. Use overlap prevention and single-server scheduling semantics on the command.
• Storage growth is the practical ceiling; retention policy is mandatory, not optional.

Failure modes (ranked by impact)

1. Monitor host down — detection and alerting die together. Mitigation: external dead-man's-switch on the scheduler heartbeat.
2. Scheduler not running — checks silently stop; no alert is generated because the alert generator is the thing that failed. Same mitigation.
3. Queue worker down with a queued notification driver — checks run, alerts never send. Mitigation: health check on queue depth and worker liveness.
4. Network egress/DNS faults on the monitor host — mass false positives across every monitor. Mitigation: tune consecutive-failure threshold; ignore-check windows during known maintenance.
5. SSL check false positives — SNI, multi-certificate, or CDN-terminated hosts. Mitigation: validate the certificate check against the actual edge before trusting it.
6. Webhook revocation / channel misconfiguration — silent alert loss. Mitigation: synthetic end-to-end test alert on a schedule.
7. Alert fatigue — hourly resends plus low consecutive-failure thresholds. Mitigation: tier-aware thresholds, per-team routing.

Ramp-up

• Engineering: ~1–2 days for a Laravel-fluent developer to integrate and prove end-to-end; +3–5 days if a minimal admin surface is required.
• Operational: ~1 day to write the runbook, define alert routing and thresholds per tier, and run a game-day that deliberately kills the scheduler and the queue worker to confirm the dead-man's switch fires.
• Organizational: 2–4 weeks of parallel running before cutover, primarily to tune thresholds against real traffic and to drain the false-positive backlog.
• Net assessment: technically sound and cheap to adopt, but it is an alerting mechanism, not a monitoring product. Budget for the missing UI, the escalation wiring, and the out-of-band watchdog — those, not the package, determine whether this is a reliable production dependency.