- How do I install spatie/laravel-uptime-monitor in a Laravel app?
- Install it with Composer using composer require spatie/laravel-uptime-monitor, then publish the package config file and migrations. The package ships a service provider and a Monitor Eloquent model that you can override through the monitor_model setting. After seeding your monitors, schedule the monitor:check-uptime and certificate check commands so checks run automatically.
- Which Laravel versions does spatie/laravel-uptime-monitor support?
- Based on the changelog trail, the package supports roughly Laravel 10 through 13: version 4.2.1 added 10.x support, 4.3.0 added 11.x, 4.5.1 added 12.x, and 4.6.0 added 13.x. Because 4.6.0 is effectively 13.x-only, adopting it may force a framework upgrade if you are on an older major version. Check the release notes for the exact constraints before committing.
- How do I configure monitors and notifications in laravel-uptime-monitor?
- Monitors are stored as Eloquent records using the Monitor model, so you seed or create them in your database and point the package at your sites. The publishable config file maps each event, such as UptimeCheckFailed or UptimeCheckRecovered, to one or more notification channels like slack and mail. You can also override the monitor_model to add domain-specific fields and customise the check interval and timeouts.
- Does spatie/laravel-uptime-monitor warn before SSL certificates expire?
- Yes. The package includes scheduled certificate checks and can notify you a few days before an SSL certificate on one of your monitored sites expires. The alert uses the same Laravel notification system as the uptime alerts, so it can go to Slack, mail, or a custom channel. This makes it useful for catching expiry problems before they turn into outages.
- Can I monitor protected endpoints with custom headers or authentication?
- Yes. The package supports Guzzle options, so you can attach headers or basic authentication when checking endpoints behind protection. For more advanced validation, such as asserting a JSON body field or a specific health-endpoint payload, you can implement a custom UptimeResponseChecker instead of relying on a simple string match. That extension point is genuinely useful for internal APIs and health checks.
- Do uptime checks require a scheduler and queue worker?
- Yes. The checks are HTTP calls issued from your own infrastructure, driven by scheduled artisan commands such as monitor:check-uptime. Notifications are sent through Laravel's notification system, so a queue worker is typically needed if your notifications are queued. This means the monitor is only as reliable as the scheduler, queue, and network egress of the app hosting it.
- Is there a built-in API or UI for creating uptime monitors?
- No. The package has no built-in API or dashboard, and the README explicitly defers to a third-party API package and the separate uptime-monitor-app repository. Any self-service monitor creation, alert-routing UI, or CRUD interface is code you build yourself. Budget for that work if you need more than seeded monitors managed through artisan or tinker.
- How do I reduce false positives and alert fatigue with laravel-uptime-monitor?
- The config exposes retry and throttling knobs such as fire_monitor_failed_event_after_consecutive_failures and resend_uptime_check_failed_notification_every_minutes, so you can require multiple consecutive failures before alerting. However, notification throttling policies, escalation rules, and on-call routing are not modelled by the package. Alert fatigue is a configuration discipline you own, so tune thresholds and timeouts deliberately.
- Can I send uptime alerts to PagerDuty, Opsgenie, or Telegram?
- The package leverages native Laravel notifications, and out of the box the config supports slack and mail. You can specify your own notification classes in the config, so writing a PagerDuty, Opsgenie, or Telegram notification is straightforward if you are comfortable with Laravel notifications. The package does not ship an escalation policy or on-call scheduling, so those integrations are your responsibility.
- Is spatie/laravel-uptime-monitor suitable for production and multi-region monitoring?
- It works well as a component inside a Laravel monolith or a dedicated internal ops app, but it is not a complete monitoring solution. Checks run from your own infrastructure, so a single always-on node becomes a correlated-failure single point of monitoring truth, and there are no multi-region vantage points or status-page publishing. If your SLO needs sub-5-minute detection or multiple locations, treat this as one layer and consider the standalone uptime-monitor-app repo or commercial synthetic monitoring. A low-risk approach is to run it alongside existing monitoring for a few weeks and reconcile the results before relying on it.