Laravel Totem Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling: Laravel Totem gives you a scheduled-task admin dashboard (view next/last run, enable/disable, run on demand, inspect output) for the cost of a composer require instead of weeks of internal UI work. The decision to weigh is "small free package" vs. "internal surface we own."
• Support and on-call workflow: the core value is cutting the time to answer "did the nightly job run?" — it replaces SSH-and-check-log spelunking and gives support/ops staff a safe place to look. That's a measurable reduction in escalations to engineers.
• Incident response: being able to toggle a misbehaving scheduled command off (or re-run a missed one) without a deploy is a real operational lever; decide whether that power belongs with engineers only or with ops.
• Roadmap signal, not roadmap driver: v13.4.0 is a dark mode for the dashboard with a Light / Dark / Browser default switcher — purely cosmetic. It indicates the maintainer is still investing in the UI, which is mildly reassuring for maintenance risk, but it should not influence prioritization. The only roadmap-relevant angle: if the dashboard is displayed on a wall/NOC screen or used during long on-call shifts, theme support is a small quality-of-life win for the people who live in it.
• Ecosystem consistency: TOTEM_THEME_STORAGE_KEY=theme lets the theme be shared with Filament's switcher — relevant only if you already run Filament; otherwise ignore it.

When to Consider This Package

Consider it when:

• You have a small-to-midsize Laravel app with a modest number of scheduled tasks and standard cron/schedule:run, and no existing visibility into them.
• Non-engineers (support, ops) need a read-mostly view of scheduled jobs without server access.
• You want zero additional infrastructure and no SaaS spend, and you're comfortable pinning and testing package upgrades.
• You have not (or only lightly) overridden Totem's views.

Look elsewhere when:

• You need alerting on failure, long-term history, or metrics — use healthchecks.io, Sentry Cron Monitoring, Oh Dear, Laravel Pulse/Nightwatch, or a proper APM. Totem shows state; it does not page anyone.
• You run multiple servers or distributed scheduling (schedule:run across a fleet, onOneServer, queue-based scheduling) — Totem's model assumes a single view of the schedule.
• You mostly care about queues, not cron — Horizon is the right tool.
• Upgrade friction is a concern: v13.4.0 requires php artisan totem:assets to publish css/dark.css, and any team that has overridden layout.blade.php or partials/sidebar.blade.php must hand-merge new lines from the README's Dark Mode section. This is a soft warning: minor releases in this package touch published assets and views, so if you've forked the UI, budget a small merge task per upgrade. Pin the version and test upgrades in staging.

How to Pitch It (Stakeholders)

To executives: Totem is a free, open-source dashboard for the scheduled jobs that run inside our Laravel app. It answers "did the nightly import run, and what did it say?" without an engineer logging into a server, and lets us pause or re-run a job during an incident without shipping code. Cost is near zero — no new infrastructure, no subscription — and the tradeoff is that it's a small community package, so we pin the version and own the upgrade testing. The latest release (v13.4.0) is a cosmetic dark mode plus a light/dark/browser-default switcher; it carries no breaking changes and requires republishing assets, so it's a low-risk, low-urgency upgrade.

To engineering: Add via Composer, run migrations, publish assets (php artisan totem:assets). It's a thin UI over Laravel's scheduler — no daemon, no new service. Upgrade note for v13.4.0: republish assets to get css/dark.css, and if we override layout.blade.php or partials/sidebar.blade.php, merge the new dark-mode lines manually. Set TOTEM_THEME_STORAGE_KEY=theme only if we want theme parity with Filament. Be explicit internally that Totem is visibility and manual control, not monitoring — failure alerting stays with our existing observability stack.