¶Running it

The three processes Félagi needs besides the web server, and what stops working without each.

¶The short version

php artisan serve                                    # or nginx, php-fpm
php artisan queue:listen --queue=broadcasts,mail,webhooks,imports,default
php artisan schedule:work                            # or a cron entry
php artisan reverb:start                             # websockets

composer dev runs all of them for local work. In production they are four supervised processes, or three plus a real web server.

Every one of them fails silently. Nothing throws, no page breaks, no log fills up — a feature simply stops happening, and the first person to notice is the one who wondered why their autopilot never ran.

¶The scheduler

Without it, four things stop and nothing says so.

One process:

php artisan schedule:work

Or one crontab line, which is what a server usually wants:

* * * * * cd /path/to/felagi && php artisan schedule:run >> /dev/null 2>&1

felagi:reap runs twice a minute, which a plain schedule:run cannot do on its own — Laravel handles the sub-minute frequency internally, so the crontab entry above is still correct.

¶Checking

php artisan schedule:list

Every command above should be listed with its next due time. If the list is empty, routes/console.php is not being loaded.

¶The queue worker

Five lanes, and the order matters.

php artisan queue:listen --queue=broadcasts,mail,webhooks,imports,default

Listing them in that order is not decoration: a live update is worthless three minutes behind a batch import, and a worker drains lanes left to right.

The whiteboard is the exception. Its changes are sent immediately rather than queued, so a board keeps working with no worker at all — see Broadcasting for why that one is different.

¶Checking

The dashboard reads the backlog and warns when nothing is draining it. From a shell:

php artisan queue:monitor broadcasts,mail,webhooks,imports,default

¶Reverb

php artisan reverb:start

Without it: live updates and whiteboard cursors stop. Everything else is unaffected, because a failed broadcast is never allowed to fail the write that caused it — see App\Support\Announce.

The whiteboard needs accept_client_events_from on the Reverb app, which is members by default. Cursors are whispered between browsers and never reach the application.

¶Commands you run by hand

Everything else is scheduled.

¶What to watch

There is no metrics endpoint and no health check. What exists:

• The dashboard warns about a stalled queue and about runtimes that have gone quiet.
• storage/logs/laravel.log has every webhook attempt, every failed delivery and every reaped task.
• /admin/runtimes shows last-heartbeat times, which is the fastest way to tell whether the daemon side is alive.

¶Not there yet

• No health endpoint. Nothing to point a monitor at.
• No metrics. No Prometheus, no queue depth over time.
• No supervisor or systemd units shipped. The commands above are the contract; how they stay running is yours.