Daily checks#

A live install has a small number of moving parts: the web app, the queue worker, the scheduler and the nightly jobs. Ten minutes each morning is enough to catch almost everything before your team notices. Work down this page in order — each step links to the page that explains the fix when something is off.

Who this is for#

• The super admin (or whoever is on point) for a live install.
• Developers covering support for a client workspace.

Difficulty: Easy · Time: about 10 minutes · Prerequisites: Super Admin access and, ideally, the ability to run php artisan on the server (or reach the cron runner).

Step 1 — Read the health endpoint#

Open GET {your app URL}/api/v1/health. It returns HTTP 200 with status: ok, or HTTP 503 with status: degraded when a core check fails:

{
  "status": "ok",
  "checks": { "db": "...", "cache": "...", "storage": "..." },
  "queue": "...",
  "version": "...",
  "timestamp": "..."
}

If it is degraded, note which of db, cache or storage failed — the same failure is written to the log as healthcheck.db.failed, healthcheck.cache.failed or healthcheck.storage.failed. Point an uptime monitor at this URL and at your login page; see Monitoring & alerts.

Step 2 — Skim Super Admin → System Health#

Open Super Admin → Settings → System Health (/super-admin/settings/system-health). On a healthy morning:

• Queue driver is not sync on production. With sync, jobs run inline inside web requests — slow integrations then block page loads, and System Health warns about it when you restart the queue.
• Debug mode is off.
• Disk usage has headroom (recordings and backups grow over time).
• The WhatsApp health card shows connections as connected, templates where you expect them, and queue_failures at 0. That count comes from failed jobs for SendLeadMessage.

The page also carries the one-click actions you will want on a bad day — Clear caches, Run migrations, Rebuild caches, Storage link and Restart queue. Incident response says when to use each.

Step 3 — Confirm last night's jobs ran#

This is what runs every night (server time):

Do not just look at the backup — verify it. The Verify action on the Backups page re-opens the archive, checks it is healthy and counts the SQL statements inside.

Step 4 — Make sure the queue and scheduler are alive#

• Failed jobs: php artisan queue:failed should be empty, or only rows you have already triaged.
• Worker: a queue:work process must be running and must listen to every queue: php artisan queue:work --queue=default,webhooks,automations,integrations,notifications,exports,ai-sdr,mail A worker that omits a queue silently starves it.
• Scheduler: php artisan schedule:run fires every minute — via cron on a VPS, or via the single cron.php entry point on shared hosting (it drains the queue with a time budget, then runs the scheduler). Every scheduled task logs its failure as schedule task failed: {name}, so searching storage/logs/laravel.log for schedule task failed is a fast check that nothing is quietly broken.

Step 5 — Glance at leads, messages and money#

• Leads: Admin → Lead Source Health Report (/admin/lead-source-health-report) and Webhook Logs (/admin/webhook-logs) — no unexpected rejected or invalid_signature rows.
• Meta issues: Super Admin → Meta Ads → Needs Attention (/super-admin/meta-ads/needs-attention) — the nav badge shows open CRITICAL issues; acknowledge the ones you are handling.
• Billing: Super Admin → Billing → Commercial (/super-admin/billing/commercial) — read the payment_failures, grace_period, restricted and suspended cards; anything unusual, see Payments failing.

Expected result#

Every check above done in about ten minutes, with nothing to fix — or a short list of specific items, each with a page that tells you how to fix it.

Common mistakes#

Troubleshooting#

Technical details#

• Scheduler definitions live in routes/console.php. Every entry logs failures via ->onFailure(...) as schedule task failed: {name}; most use ->withoutOverlapping(10).
• High-frequency tasks: every 5 minutes (IMAP mailbox checks, appointment reminders, follow-up due checks, tasks:send-reminders); hourly (notifications:digest, reports:deliver, filters:send-alerts, payment failure checks); every 15 minutes (ProcessEmailSequences, ProcessAiSdrEnrollments, leadhub:sync-calendars); every 30 minutes (leadhub:meta-ops-scan, provider reconciliation, applied change requests); every 6 hours (leadhub:meta-health).
• The health endpoint is App\Http\Controllers\Api\HealthController at GET /api/v1/health — public, 200/503.

Related guides#

• Monitoring & alerts
• Incident response
• Queues, jobs & scheduler
• Deployment & server errors