Sign up now for $10 in credit on a new Laravel Cloud account.
Confidently own your tech stack
scalpels.app
A nightly backup that quietly stopped running three weeks ago is not an incident anything reports. Muster gives every scheduled task an expected rhythm and complains when a run does not arrive — late, then missed, by email or webhook — on hardware you already pay for, with no per-monitor pricing.
Work in progress. Available to supporters.
One question, answered honestly: did the thing report in on time?
A cron expression or a plain period, plus a grace window, is the whole definition — a job that usually takes four minutes gets a grace period longer than four minutes.
Connect a Laravel app and every scheduled command becomes a monitor on its first run, using the command's real cron expression and timezone.
Muster tracks runs that started and never finished, runs that exited non-zero, and runs that were skipped, not just the silence between them.
Two thresholds, evaluated every minute. A monitor can pass through late into missed in a single pass when both are already behind it.
Email and webhook are independent channels, and you choose which failures each one carries. One alert per incident, and one when it recovers.
Every Monday, the previous UTC week's failures to every active account user — including a clean week, which sends an all-clear rather than nothing.
Muster never reads or stores your task's output. No stdout, no stack traces, no payloads — just whether the run reported in and how it ended. Nothing sensitive crosses the boundary, the database stays small, and there is exactly one question to answer when it goes red.
The Laravel client subscribes to the framework's own schedule events, so a command you added this morning is a monitor this evening without anyone registering it. A cron job on a box that is not Laravel checks in with one authenticated HTTP request instead.
Muster vs. the incumbents
Healthchecks.io, Cronitor and Oh Dear are good products, and Muster is not trying to replace them. It does one slice of what they do — notice when a scheduled task stops reporting in — on infrastructure you own, and deliberately does not do the rest. The question is not which product is better. It is which slice you are actually using.
| Feature | Muster Self-hosted, MIT | Healthchecks.io Hosted, or self-host | Cronitor Hosted | Oh Dear Hosted |
|---|---|---|---|---|
| Check-in history on infrastructure you own the row we rebuilt | Does this well:Your Cloud account | Partly, or with a caveat:Self-host available | Not built:Hosted only | Not built:Hosted only |
| A Laravel schedule registering itself the row we rebuilt | Does this well:Every command, first run | Not built:Register by hand | Partly, or with a caveat:Generic integrations | Partly, or with a caveat:Laravel package |
| Start, finish and exit-code tracking | Does this well:All four states | Does this well:Included | Does this well:Included | Does this well:Included |
| Capturing the task's output we did not build this | Not built:Never stored | Does this well:Included | Does this well:Included | Partly, or with a caveat:Limited |
| Uptime, SSL and broken-link checks we did not build this | Not built:Schedules only | Not built:Schedules only | Does this well:Included | Does this well:Their core strength |
| SMS, phone, Slack and pager routing we did not build this | Not built:Email and webhook | Does this well:Many channels | Does this well:Many channels | Does this well:Many channels |
| On-call rotations and escalation we did not build this | Not built:Not built | Not built:Not built | Works, but on their terms:Higher plans | Partly, or with a caveat:Via integrations |
| Where your check-in history lives | Does this well:Your own database | Partly, or with a caveat:Theirs, or yours | Works, but on their terms:Their cluster | Works, but on their terms:Their cluster |
| Cost of the next monitor | Does this well:A database row | Works, but on their terms:Per check, by plan | Works, but on their terms:Per monitor | Works, but on their terms:Per site, by plan |
| Who is on call for the tool itself | Partly, or with a caveat:You are | Does this well:They are | Does this well:They are | Does this well:They are |
Ask what the cron monitor is actually for on your team. If these are all true, you are paying per monitor for a suite to use one row of it.
Then you lose very little by moving. Muster is experimental today, so start by pointing one noisy schedule at it; the history stays in your own database either way.
These are the parts we chose not to build, and we are not going to pretend otherwise.
Small, sharp tools are a deliberate scope, not an unfinished roadmap. Muster will not grow into an observability platform.
Be honest about it
The repository is public and open source. These are the steps, and you are welcome to spend the afternoon doing them by hand.
Fork the Muster repository into your own GitHub organisation.
Deploy the fork to Laravel Cloud with its own compute, Postgres, a managed queue and the scheduler enabled, then point it at a mail transport that really delivers.
Install the client in your Laravel app and let its schedule register itself, or check in from anything else with one authenticated HTTP request.
Or become a supporter, and Scalpels deploys it for you. It forks it, provisions exactly what it needs on your Laravel Cloud account, and deploys it. The app and the infrastructure are yours either way — the only question is who spends the afternoon.
Deploy Muster as a supporterThese agencies and freelancers are standing by and ready to help.
Michigan
PHP and Laravel developer with 13 years of experience building and maintaining production apps. US Eastern, English.
USA
We run Scalpels, as well as a suite of other tools for developers and development teams.
Muster tells you a scheduled job stopped reporting in; Hone tells you what it was doing when it was still running. Bobbin is the same question pointed at the requests arriving from outside, and Capstan is the schedule an agent ecosystem keeps.