Laravel Totem gives the scheduler a dashboard and a Pause All button

The gap Totem fills: scheduling lives in code, incidents happen in dashboards

Laravel's scheduler is declared in code, in the `Schedule` facade, and it fires because a single cron entry runs `schedule:run` every minute. That design is good for reproducibility and poor for 3am: when a nightly import is queueing work it should not be, the way to stop it is a commit, a push and a deploy.

Totem's pitch is to give that same scheduler a web interface. The README describes managing the Laravel schedule from a dashboard, scheduling Artisan console commands to your liking, and enabling or disabling scheduled tasks on the fly without going back to your code.

The audience is shared-staging-production teams who want operators, support staff or on-call engineers to influence scheduled jobs without filesystem or deploy access. It is not a general queue dashboard; the project is scoped to the schedule.

One more thing the README advertises: Totem can send notifications when a task completes. Email notifications are included out of the box, and SMS and Slack channels arrive as optional Composer packages rather than being bundled.

Pause All is the feature that changes incident response

The most consequential paragraph in the README is the one about pausing. You can pause the scheduled runs of every task at once, for example during an incident or a deploy. Each task keeps its own enabled or disabled setting, so resuming puts everything back exactly as it was.

That distinction is the whole design. A naive kill switch that resets every task to disabled destroys information: after the incident nobody can tell which tasks were genuinely meant to run. Totem's global pause is a separate layer above per-task state, so the resume is a true restore rather than a guess.

Manual execution survives the pause. The README states that running a task manually with the Execute button still works while tasks are paused. That combination is what makes the feature usable during an incident: freeze the automatic firing, run the one job you need by hand, resume.

From the dashboard the control is Pause All at the bottom of the task list, and you can pause until you resume manually. The README is truncated at that point, so the finer options for the pause duration are not visible here and would need checking against the docs directory in the repository.

Installing on Laravel 13 takes three commands, then a real cron entry

The install path is short. The README asks you to understand Laravel's task scheduling and Artisan console commands before starting, which is fair advice given what follows.

composer require studio/laravel-totem

Then run the migration and publish the assets:

php artisan migrate
php artisan totem:assets

`php artisan migrate` creates Totem's tables, which is why the package stores its task definitions in the database rather than parsing your code on each request. `php artisan totem:assets` publishes the front end assets into your public directory.

The `totem:assets` command reappears after every upgrade. The README is explicit: republish Totem assets after updating to a new version. A deployment that upgrades the package but skips that command will be missing asset files, including the dark stylesheet.

Finally, nothing works until cron actually runs the scheduler. The README states the exact entry:

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

With that in place, the dashboard is reachable at `/totem` of your app.

The dashboard is local-environment-only until you write an auth callback

This is the security detail most people will get wrong, so read it twice. By default Totem's dashboard only works in the local environment.

To open it up, the README says to configure authentication in the `boot` method of your `AppServiceProvider`, in the same spirit as Laravel Horizon:

use Studio\Totem\Totem;

Totem::auth(function($request) {
    return Auth::check();
});

The closure returns a boolean, and the README comment shows exactly that shape. The example delegates to your existing session, but nothing constrains you to that; the return value is yours to decide.

Middleware is configurable too. Totem uses the `web` middleware group by default, and if you need something else you set `TOTEM_WEB_MIDDLEWARE` in your `.env`, taking the values from `config/totem.php`.

A dashboard that can run your Artisan commands on demand is a remote execution surface by design. The local-environment default is the safety net, and the README never asks you to remove it.

Every Artisan command is schedulable unless you mark it hidden

Totem's data model is a task row pointing at an Artisan command plus a cron expression plus parameters. The command pool is wide open by default: all Artisan commands are available for scheduling.

Hiding one is a property on the command class itself:

protected $hidden = true;

Set that in your command and Totem will not offer it. Note the mechanism: it reuses the console's own visibility flag rather than maintaining a Totem-side denylist, which means a command hidden from the CLI is hidden from the dashboard by the same declaration.

Commands that need input use the optional command parameters field, entered as a string:

name=john.doe --greetings='Welcome to the new world'

In that example `name` is an argument and `greetings` is an option. The README does not document escaping rules beyond this format, so treat quoting as the only guidance available.

You can also see the resulting schedule from the console with:

php artisan schedule:list

Totem adds that command for listing scheduled tasks; it is the quickest way to confirm that what you saved in the dashboard is what the scheduler will actually run.

Four environment variables solve the collisions teams actually hit

The configuration surface is mostly `.env` keys, and each one exists because of a specific failure.

`TOTEM_TABLE_PREFIX` addresses name collisions. Totem's tables use generic names which may conflict with existing tables in a project, so setting this parameter applies a prefix to all of Totem's tables and their models.

`TOTEM_CACHE_STORE` addresses split cache clusters. By default Totem uses your application's default cache store. The README spells out the failure: in environments where UI servers and background worker servers use separate cache clusters, for example different Redis instances, Totem's cache can become inconsistent, so a bust event on one server will not clear the cache on the other. Set it to a named store from your `config/cache.php` that every server can reach, or set it to `array` to disable persistence entirely so each request hits the database.

`TOTEM_THEME_STORAGE_KEY` renames the localStorage key holding the theme choice, which is `totem-theme` by default. The default theme switcher offers Light, Dark and Browser default, and Browser default is the starting choice. Filament stores the same values, `light`, `dark` and `system`, under the key `theme`, so setting `TOTEM_THEME_STORAGE_KEY=theme` lets a Filament app share one preference across its panels and Totem.

The command dropdown is configured in `totem.php` rather than `.env`, using `command_filter` with fnmatch patterns such as `stats:*`, which can act as a whitelist or, with `'whitelist' => false`, as a blacklist.

Version pairing, licence and the cost of staying current

Totem tracks Laravel majors closely, and the compatibility matrix is the first thing to check. The current line is Totem 13.x, which the README lists against both Laravel 13.x and Laravel 12.x; requirements for that line are PHP 8.3+ and Laravel 12.x or 13.x.

Older pairs are still supported rather than abandoned. Totem 12.x supports Laravel 11.x and 12.x with PHP 8.2+, and Totem 11.x supports Laravel 10.x, 11.x and 12.x, also on PHP 8.2+. The repository's default branch is 13.x,: v13.4.0, v13.3.0 and v13.2.0 landed on 2026-10-13, 2026-10-08 and 2026-10-01 respectively. The last push was on 2026-10-13, so the current line is receiving updates.

The upgrade cost is mostly procedural rather than technical. There is no schema migration guide in the README, only the reminder to re-run `php artisan totem:assets` after each version bump. If you have edited published assets, that command overwrites them; the README does not describe a way to keep local modifications.

The licence is MIT, which permits use, modification and redistribution in commercial and non-commercial contexts with the notice preserved. That is the terms of the licence, not advice about how it fits your deployment.

Editorial conclusion

Adopt Laravel Totem on Laravel 12 or 13 with PHP 8.3 or higher if your team needs to flip scheduled tasks without a deploy, especially during incidents where the Pause All control matters. Do not install it on a version outside the compatibility matrix without picking the matching Totem major, and do not expose `/totem` publicly until you have set the `Totem::auth` callback, because the dashboard is local-environment-only by default. Verify first that your cron entry runs `schedule:run` every minute, and if your UI and worker servers use different cache clusters, set `TOTEM_CACHE_STORE` to a shared store before trusting what the dashboard shows.

Frequently asked questions

Official sources

1. always-open/laravel-totem on GitHub
2. Issues
3. License: MIT
4. README
5. Releases