jobs table not created on a fresh install with QUEUE_CONNECTION=database

[yylian]

Disclaimer: Yes, this issue was written by AI, but reviewed by a human. The bug was found by a human and verified by a human.

What I ran into

Fresh install on the 3.x branch. Copied .env.example, ran php artisan migrate, started a worker, and every job fails with:

SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "jobs" does not exist

I wanted to check whether I've missed an install step, since the surrounding config looks deliberate.

What I see

.env.example:37 ships QUEUE_CONNECTION=database, and config/queue.php:25 also defaults to database, so I didn't opt into that driver, it looks like the default.

The shipped migrations include create_failed_jobs_table, create_cache_table and create_sessions_table, but I can't find a create_jobs_table anywhere in the app or in cachethq/core.

Why I think this may be unintentional

A stock laravel/laravel 12.x app ships 0001_01_01_000002_create_jobs_table.php by default, precisely because its .env.example defaults to QUEUE_CONNECTION=database. (Before Laravel 11 the default was
sync and you generated the migration with php artisan queue:table, which still exists.)

Impact, for context

9 classes implement ShouldQueue, so this isn't limited to email:

• Cachet\Jobs\CheckComponent — component health checks never run
• NewIncidentNotification, IncidentUpdatedNotification, ScheduleUpdatedNotification, VerifySubscriberEmail — subscribers are never notified and address verification never completes

Nothing surfaces in the UI. It appears only in the log, once per queue:work invocation, so an operator can believe notifications are working for a long time. The ShouldQueue classes live in cachethq/core,
but the queue config and migration set are app-level, which is why I'm filing here.

Reproduce

1. Fresh install, .env copied from .env.example unmodified
2. php artisan migrate
3. php artisan queue:work → fails immediately

Environment

• Cachet 3.x @ 264ba3ec
• cachethq/core dev-main @ 17f1bd0
• Laravel 13.24.0, PHP 8.4.24, PostgreSQL 17.10 (doesn't appear database-specific)

Question

Is the jobs table meant to be created by the operator — in which case the install docs could mention php artisan queue:table — or should the migration ship alongside the cache/sessions ones?

For now I've added Laravel's stock queue migration to my own deployment and the workers run fine. Happy to open a PR if the latter.

[yylian]

I just realized this would be better filed in https://github.com/cachethq/cachet . Maybe you can transfer the issue :-)